feat(azure_openai): attach Dify app_id as request metadata (opt-in)

[mas-sakai]

Summary

Adds opt-in support for attaching the Dify app_id as Azure OpenAI request metadata, so per-app usage can be filtered in Stored Completions.

When the new enable_request_metadata credential is set to enabled, the plugin reads app_id from the current Dify session (via get_current_session() from the SDK) and attaches {dify_app_id, dify_source} as the metadata field on both the Chat Completions route (chat.completions.create) and the Responses route (responses.create). The default is disabled, so behavior is unchanged unless the operator opts in.

This is the Azure OpenAI counterpart of the same feature already shipped for Vertex AI (#3168), Bedrock (#3201), and OpenAI (#3203). The responsibility split mirrors those plugins:

Plugin	What the plugin attaches	What the operator must enable
Vertex AI	labels on generateContent	BigQuery billing export
Bedrock	requestMetadata on Converse	CloudWatch invocation logging
OpenAI	metadata on Chat / Responses	Stored Completions (account-level)
Azure OpenAI	metadata on Chat / Responses	Stored Completions (Azure resource)

Design note: store is deliberately not set

The plugin does not set store=true on requests. Whether metadata persists and surfaces depends entirely on the Stored Completions setting of the Azure OpenAI resource, which the resource owner controls. Setting store from inside the plugin would change persistence behavior as a side effect of a telemetry opt-in — same responsibility split as OpenAI (account-level Stored Completions), Bedrock (CloudWatch), and Vertex (billing export). The credential's help text in provider/azure_openai.yaml documents this expectation in both English and Simplified Chinese.

See: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/stored-completions

Related:

• Pass app_id to model plugins for provider-side cost attribution dify#35772
• Pass session (with app_id) to model plugin instances (parity with tool plugins) dify-plugin-sdks#311
• feat: expose session context to model plugins via get_current_session() dify-plugin-sdks#313 (SDK branch this plugin currently pins)
• feat(vertex_ai): support GenerateContentConfig labels for Dify app_id propagation #3168 (Vertex AI counterpart)
• feat(bedrock): attach Dify app_id as Converse requestMetadata (opt-in) #3201 (Bedrock counterpart)
• feat(openai): attach Dify app_id as request metadata (opt-in) #3203 (OpenAI counterpart)

Note

Draft / dependency. pyproject.toml temporarily pins dify_plugin to the fork branch ryuta-kobayashi-ug/dify-plugin-sdks@feat/pass-session-to-model-plugins because it carries the get_current_session() API used here (langgenius/dify-plugin-sdks#313). The pin will revert to a versioned dify_plugin spec once that SDK change merges and a release ships.

Change Type

• Documentation / non-plugin change
• Non-LLM plugin (tools, extensions, datasource, etc.)
• LLM plugin

Screenshots / Videos

Before	After
Stored Completions rows are anonymous; per-app filtering is impossible.	With opt-in enabled and Stored Completions enabled on the Azure OpenAI resource, requests carry dify_app_id and dify_source, enabling per-app filtering.

End-to-end screenshots will be added once the dependent SDK change (#313) ships and a Dify deployment can be exercised against a live Azure OpenAI resource with Stored Completions enabled.

LLM Plugin Checklist

Areas affected by this change

• Message flow (system messages, user ↔ assistant turn-taking)
• Tool interaction flow (multi-round usage, Agent App and Agent Node)
• Multimodal input (images, PDFs, audio, video, etc.)
• Multimodal output (images, audio, video, etc.)
• Structured output (JSON, XML, etc.)
• Token consumption metrics
• Other LLM functionality (reasoning, grounding, prompt caching, etc.) — request metadata for billing/observability
• New models / model parameter fixes

The change is additive and behind a credential that defaults to disabled. No existing message flow, tool, multimodal, structured-output, or token-accounting code path is altered. Only _chat_generate (Chat Completions route) and _chat_generate_with_responses (Responses route) gain a one-line opt-in hook that mutates the request kwargs immediately before the Azure OpenAI client call. The legacy _generate completions route is intentionally left untouched.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces support for attaching Dify metadata (dify_app_id and dify_source) to Azure OpenAI Chat Completions and Responses API requests. This feature is opt-in and can be enabled via the new enable_request_metadata configuration option. The implementation includes helper functions for metadata normalization and injection, integrated into the LLM generation flows, along with corresponding unit tests and dependency updates. Feedback on the changes suggests avoiding in-place mutation of the existing metadata dictionary to prevent side effects, and adding an explicit check for None in the normalization helper to avoid converting it to the literal string 'None'.