fix: report versioned Fabric runtime metadata - #2665
Conversation
AB#5533937 ## Summary Add a cached Fabric runtime identity to PlatformDetails and use it in SynapseML OpenAI extended properties. Fabric requests now report fabric_spark_<spark_version>, fall back to fabric_python_<python_version> when Spark is unavailable, and finally use fabric. ## Prompting Intent The engineer asked for a new SynapseML follow-up PR that replaces the generic runtime value in Fabric LLM taxonomy metadata with versioned Spark or Python runtime attribution and ensures detection is performed only once. ## Linked Sources - Work item: https://dev.azure.com/msdata/A365/_workitems/edit/5533937 - Prior header PR: microsoft#2656 - Fabric taxonomy guidance: https://eng.ms/docs/synapse-data-science-fabric-product-synapse-data-science/llmendpoint/partnerdocs/taxonomyandclassofservice.html ## Rationale Place runtime detection in shared PlatformDetails rather than the OpenAI header trait so the taxonomy value has one owner. A lazy value guarantees one-time process detection. Spark version is authoritative for SynapseML JVM execution; an environment or JVM Python version remains available as a defensive fallback before the generic fabric value. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d835d0c8-9ce7-4f84-99a6-a7c87b24058c
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Hey Rana Singh (@ranadeepsingh) 👋! We use semantic commit messages to streamline the release process. Examples of commit messages with semantic prefixes:
To test your commit locally, please follow our guild on building from source. |
There was a problem hiding this comment.
Pull request overview
This PR updates Fabric LLM taxonomy metadata so SynapseML reports a versioned Fabric runtime string in X-Taxonomy-ExtendedProperties, enabling downstream workload classification to distinguish Spark vs Python runtimes (and include their versions).
Changes:
- Introduces
PlatformDetails.FabricRuntime(lazy) andresolveFabricRuntime(...)to producefabric_spark_<sparkVersion>,fabric_python_<pythonVersion>, orfabric. - Switches OpenAI Fabric taxonomy header generation to use
PlatformDetails.FabricRuntimeinstead ofCurrentPlatform. - Adds/updates targeted Scala tests for the new runtime resolution behavior and updated header expectation.
Show a summary per file
| File | Description |
|---|---|
| core/src/main/scala/com/microsoft/azure/synapse/ml/logging/common/PlatformDetails.scala | Adds Fabric-specific runtime resolution and exposes FabricRuntime for shared use. |
| core/src/test/scala/com/microsoft/azure/synapse/ml/logging/common/VerifyPlatformDetails.scala | Adds unit tests validating FabricRuntime stability and fallback ordering. |
| cognitive/src/main/scala/com/microsoft/azure/synapse/ml/services/openai/OpenAI.scala | Updates Fabric header runtime attribution to use PlatformDetails.FabricRuntime. |
| cognitive/src/test/scala/com/microsoft/azure/synapse/ml/services/openai/OpenAIFabricHeadersSuite.scala | Updates expected runtime string in extended properties header assertions. |
Review details
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
- Files reviewed: 4/4 changed files
- Comments generated: 1
- Review effort level: Lite
AB#5533937 ## Summary Align SynapseML runtime resolution exactly with SynapseML-Internal and initialize the complete fixed Fabric LLM classification header map once per JVM. Reuse that immutable map across OpenAI request rows while preserving request-specific custom-header merging. ## Prompting Intent The engineer asked to make the SynapseML follow-up use the same runtime algorithm as SynapseML-Internal and ensure all runtime-stable headers are initialized once rather than rebuilt for repeated requests. ## Linked Sources - Work item: https://dev.azure.com/msdata/A365/_workitems/edit/5533937 - Pull request: microsoft#2665 - Internal AI Functions PR: https://dev.azure.com/msdata/A365/_git/SynapseML-Internal/pullrequest/2253680 - Fabric guidance: https://eng.ms/docs/synapse-data-science-fabric-product-synapse-data-science/llmendpoint/partnerdocs/taxonomyandclassofservice.html ## Rationale A JVM-wide lazy immutable map avoids repeated JSON serialization and classification-map allocation. Headers are still attached to every outbound request, as required by HTTP, while only caller-specific merging remains per request. Matching the internal resolver removes the extra JVM property fallback and keeps both codebases behaviorally identical. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d835d0c8-9ce7-4f84-99a6-a7c87b24058c
AB#5533937 ## Summary Return `unknown` from SynapseML Fabric runtime metadata when Fabric detection is false, while retaining versioned Spark and Python runtime values on Fabric. ## Prompting Intent The engineer clarified that SynapseML can run on Databricks or locally and requested an unknown runtime when the Synapse-internal/Fabric helper returns false. Keep the public and internal implementations aligned. ## Linked Sources - Work item: https://dev.azure.com/msdata/A365/_workitems/edit/5533937 - Pull request: microsoft#2665 - Internal AI Functions PR: https://dev.azure.com/msdata/A365/_git/SynapseML-Internal/pullrequest/2253680 ## Rationale The taxonomy runtime field is intended to describe Fabric execution. Mapping non-Fabric platforms such as Databricks into that field would create misleading categories, so a stable `unknown` fallback is clearer and consistent across implementations. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d835d0c8-9ce7-4f84-99a6-a7c87b24058c
There was a problem hiding this comment.
Review details
Suppressed comments (1)
core/src/main/scala/com/microsoft/azure/synapse/ml/logging/common/PlatformDetails.scala:20
FabricRuntimeis currently always resolved fromOption(org.apache.spark.SPARK_VERSION), which is effectively alwaysSome(nonEmpty)when Spark is on the classpath. That means the advertised fallback tofabric_python_<python_version>/fabricwhen Spark is unavailable will never be taken, which conflicts with the PR description’s runtime selection rules.
lazy val FabricRuntime: String = resolveFabricRuntime(
runningOnFabric(),
Option(org.apache.spark.SPARK_VERSION),
sys.env.get("PYTHON_VERSION")
)
- Files reviewed: 4/4 changed files
- Comments generated: 0 new
- Review effort level: Lite
AB#5533937 ## Summary Guard Spark version lookup so the Python/Fabric fallback remains safe when Spark linkage is unavailable, and rename cached header fields to satisfy SynapseML Scala style rules. ## Prompting Intent Run the SynapseML PR readiness loop, address every current-head review finding, and make all required validation checks pass. ## Linked Sources - Pull request: microsoft#2665 - Review thread: microsoft#2665 (comment) - Work item: https://dev.azure.com/msdata/A365/_workitems/edit/5533937 ## Rationale Catching Spark linkage failure at the version lookup preserves the documented fallback without changing the normal Spark-first path. Renaming object fields fixes the CI style failure while retaining one-time immutable header initialization. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d835d0c8-9ce7-4f84-99a6-a7c87b24058c
|
Addressed the current-head suppressed review finding in 9fbfbc5: Spark version lookup now safely handles unavailable Spark linkage, while retaining Spark-first behavior when packaged. Local Scala style and targeted suites pass. |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2665 +/- ##
==========================================
- Coverage 87.19% 87.19% -0.01%
==========================================
Files 337 337
Lines 19554 19559 +5
Branches 1894 1942 +48
==========================================
+ Hits 17050 17054 +4
- Misses 2504 2505 +1
🚀 New features to boost your workflow:
|
|
PR-loop validation is complete for the current head (\9fbfbc5): latest automated review covers the head with no findings, all review threads are resolved, Scala/test scalastyle passed, \VerifyPlatformDetails\ passed 11/11, and \OpenAIFabricHeadersSuite\ passed 7/7. Full Azure CI was run twice: 231733174 and 231746576. Both were blocked before relevant product tests by external infrastructure failures (unresolved Maven dependency; the rerun also hit conda-forge HTTP 403 and an 8.6-GB cache download timeout). The same Maven resolution failure is present on a recent \master\ build 231649114. Relevant published test runs that completed were green; no product-code test failure was identified. |
AB#5533937 ## Summary Inline the canonical Fabric LLM taxonomy and service-tier wire names where the cached SynapseML header map is built. ## Prompting Intent The engineer asked to review all related repositories and PRs for exact header capitalization, calling out SynapseML PR microsoft#2665 as misleading or incorrect. ## Linked Sources - Fabric taxonomy and class-of-service guidance: https://eng.ms/docs/synapse-data-science-fabric-product-synapse-data-science/llmendpoint/partnerdocs/taxonomyandclassofservice.html - SynapseML PR: microsoft#2665 - Work item: https://dev.azure.com/msdata/A365/_workitems/edit/5533937 ## Rationale The emitted wire names already matched the documented contract. Inlining the exact literals removes confusion caused by Scala object-field capitalization while retaining JVM-wide cached header construction and making review against the specification direct. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d835d0c8-9ce7-4f84-99a6-a7c87b24058c
|
/copilot review |
|
Header-capitalization audit completed across SynapseML, SynapseML-Internal, and workload-ml. The canonical wire names are \X-Taxonomy-TrafficType, \X-Taxonomy-ExtendedProperties, and \x-llm-service-tier. Commit \�365962e1b\ removes the misleading capitalized Scala header-name fields and inlines those exact documented literals in the cached map. SynapseML-Internal and workload-ml already emit the same exact names, so they require no follow-up change. |
AB#5533937 ## Summary Emit the Fabric LLM service-tier header as `X-Llm-Service-Tier` and update the exact-casing regression test. ## Prompting Intent The engineer clarified that the Fabric documentation requires `X-Llm-Service-Tier` and asked for consistent capitalization across SynapseML, SynapseML-Internal, and workload-ml. ## Linked Sources - Fabric taxonomy and class-of-service guidance: https://eng.ms/docs/synapse-data-science-fabric-product-synapse-data-science/llmendpoint/partnerdocs/taxonomyandclassofservice.html - SynapseML PR: microsoft#2665 - Work item: https://dev.azure.com/msdata/A365/_workitems/edit/5533937 ## Rationale Although HTTP header lookup is case-insensitive, emitting the documented spelling keeps telemetry, diagnostics, tests, and code review aligned with the Fabric contract. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d835d0c8-9ce7-4f84-99a6-a7c87b24058c
|
/copilot review |
|
Corrected the emitted service-tier wire name to the documented \X-Llm-Service-Tier\ in commit \c7067331ca. The exact-casing regression test now asserts this spelling; the targeted suite passes 7/7 and Scala/test scalastyle are clean. |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
349320b
into
microsoft:master
Summary
Update SynapseML Fabric LLM extended properties to report a versioned runtime:
{"feature":"synapseml","runtime":"fabric_spark_<spark_version>|fabric_python_<python_version>|fabric|unknown"}Runtime selection matches SynapseML-Internal:
unknownfor local, Databricks, and other non-Fabric environments.fabric_spark_<spark_version>.fabric_python_<python_version>.fabric.Implementation
PlatformDetails.FabricRuntimeas the shared runtime taxonomy owner.lazy val, so runtime detection runs once per JVM.functionfield because this shared OpenAI transport represents generic SynapseML stages rather than an individual AI Functions operation.Headers must still be attached to every outbound HTTP request, but their runtime detection and fixed value construction are not repeated.
Validation
VerifyPlatformDetails: 11 passed.OpenAIFabricHeadersSuite: 7 passed.master.References