[DPS] Migrate dataplane API to typespec (stable/2021-10-01 + preview/2025-07-01-preview) by pratik11jain · Pull Request #42175 · Azure/azure-rest-api-specs

pratik11jain · 2026-04-07T20:42:26Z

Data Plane API Specification Update Pull Request

Tip

Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

PR review workflow diagram

Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

API Info: The Basics

Most of the information about your service should be captured in the issue that serves as your API Spec engagement record.

Link to API Spec engagement record issue:

Is this review for (select one):

a private preview
a public preview
GA release

Change Scope

Design Document: N/A — TypeSpec migration only (no API behavior changes)
Previous API Spec Doc: specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/stable/2021-10-01/ and preview/2025-07-01-preview/
Updated paths:
- specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/device/ (new TypeSpec source)
- specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/service/ (new TypeSpec source)
- specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/stable/2021-10-01/device.json
- specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/stable/2021-10-01/service.json
- specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/preview/2025-07-01-preview/device.json
- specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/preview/2025-07-01-preview/service.json
- specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/TYPESPEC-MIGRATION.md

Viewing API changes

For convenient view of the API changes made by this PR, refer to the URLs provided in the table in the Generated ApiView comment added to this PR.

Breaking change summary: Zero breaking changes. See TYPESPEC-MIGRATION.md in this PR for the full per-file diff analysis confirming all paths, operations, response codes, headers, required fields, and error schemas are identical.

Suppressing failures

Suppressions are defined in suppressions.yaml (carried over from original swagger). No new suppressions added.

Release planner

This is a TypeSpec migration PR — no new API surface is being added. No SDK release plan required.

How to build

cd specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices
npx tsp compile device/
npx tsp compile service/

## ❔Got questions? Need additional info?? We are here to help!

<details>
  <summary> Contact us!</summary>

The [Azure API Review Board](https://aka.ms/azsdk/onboarding/restapischedule) is dedicated to helping you create amazing APIs. You can read about our mission and learn more about our process on our [wiki](https://aka.ms/azsdk/onboarding/restapischedule).
* 💬 [Teams Channel](https://teams.microsoft.com/l/channel/19%3a3ebb18fded0e47938f998e196a52952f%40thread.tacv2/General?groupId=1a10b50c-e870-4fe0-8483-bf5542a8d2d8&tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47)
* 💌 [email](mailto://azureapirbcore@microsoft.com)

</details>

<details>
  <summary>Click here for links to tools, specs, guidelines & other good stuff</summary>

### Tooling

 * [Open API validation tools](https://aka.ms/swaggertools) were run on this PR. Go here to see [how to fix errors](https://aka.ms/ci-fix)
 * [Spectral Linting](https://github.com/Azure/azure-api-style-guide/blob/main/README.md)

### Guidelines & Specifications

 * [Azure REST API Guidelines](https://aka.ms/azapi/guidelines)
 * [OpenAPI Style Guidelines](https://aka.ms/azapi/style)
 * [Azure Breaking Change Policy](https://aka.ms/AzBreakingChangesPolicy)

### Helpful Links

 * [Schedule a data plane REST API spec review](https://aka.ms/azsdk/onboarding/restapischedule)

</details>

## Getting help

- First, please carefully read through this PR description, from top to bottom.
- If you don't have permissions to remove or add labels to the PR, request `write access` per [aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories](https://aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories) 
- To understand what you must do next to merge this PR, see the `Next Steps to Merge` comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
- For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure 
  and https://aka.ms/ci-fix.
- If the PR CI checks appear to be stuck in `queued` state, please add a comment with contents `/azp run`.
  This should result in a new comment denoting a `PR validation pipeline` has started and the checks should be updated after few minutes.
- If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

github-actions · 2026-04-07T20:43:08Z

Next Steps to Merge

✅ All automated merging requirements have been met! To get your PR merged, see aka.ms/azsdk/specreview/merge.

Comment generated by summarize-checks workflow run.

github-actions · 2026-04-15T16:16:07Z

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
Swagger	DeviceProvisioningServices-DeviceProvisioningServices
TypeSpec	ProvisioningDeviceClient
TypeSpec	ProvisioningServiceClient

Comment generated by After APIView workflow run.

pratik11jain · 2026-04-15T18:35:45Z

Breaking Change Analysis — commit `ef24753`

The BreakingChange CI flagged 4 violations when comparing the TypeSpec-generated stable/2021-10-01/service.json against the same file in main. After analysis, 2 are now fixed:

#	Type	Field	Status
BC1	`RequestParameterFormatChanged` (int32→int64)	`x-ms-max-item-count` request header	✅ Fixed — reverted to `int32` to match stable in main
BC2	`ResponseHeaderFormatChanged` (int32→int64)	`x-ms-max-item-count` response header	✅ Fixed — reverted to `int32` to match stable in main
BC3	`ReferenceRedirection` + ~~`XmsEnumChanged`~~	`BulkEnrollmentOperation.mode`	✅ XmsEnumChanged fixed (reverted to `OperationMode`); `ReferenceRedirection` unavoidable
BC4	`ReferenceRedirection` + ~~`XmsEnumChanged`~~	`BulkEnrollmentGroupOperation.mode`	✅ XmsEnumChanged fixed; `ReferenceRedirection` unavoidable

Remaining (2 unavoidable): The ReferenceRedirection violations are inherent to TypeSpec — it always extracts named type definitions to top-level definitions and cannot emit inline enum schemas as the original handwritten swagger had. These require the aka.ms/brch approval process with the justification: TypeSpec migration artifact — inline enum extracted to named definition; wire values and behavior unchanged.

@added

…e + preview) Migrates the Azure IoT Hub Device Provisioning Service data-plane REST API from handwritten Swagger 2.0 to TypeSpec for both device and service APIs across stable (2021-10-01) and preview (2025-07-01-preview) versions. TypeSpec source: - device/: runtime registration API - service/: enrollment management API Key changes: - Single TypeSpec source emits both stable and preview swagger simultaneously - Preview-only features gated with @added(Versions.v2025_07_01_preview) - LRO 202 responses explicitly modeled with retry-after and Location headers - Free-form JSON fields use Record<unknown> to preserve additionalProperties behavior - Default values restored: provisioningStatus, iotEdge, reprovision policy flags - Query response headers documented: x-ms-continuation, x-ms-item-type, x-ms-max-item-count - Added 4 new device preview examples missing from original swagger - Fixed azure-arm: true to false in readme.csharp.md - Added clientLocation for registerDeviceAndIssueCertificate in device/client.tsp No service-side changes. All wire contracts preserved. Old SDKs remain compatible. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

@minlength

…ggers - device/routes.tsp: rename body param to 'deviceRegistration' in RegisterDeviceAndIssueCertificate - device/examples/2025-07-01-preview: fix 'title' fields in MaximumSet/MinimumSet source example files - service/routes.tsp: wrap runBulkOperation body as named 'bulkOperation' param (both stable + preview ops) - service/models.tsp: TwinCollection uses Record<{}> for additionalProperties; add @minlength(1) to 8 string properties - Regenerate preview/2025-07-01-preview/device.json and service.json, stable/2021-10-01/service.json - TYPESPEC-MIGRATION.md: correct Record<unknown> references to Record<{}>; update additionalProperties table All 12 validation checks pass (paths, operationIds, HTTP methods, response codes, required fields, x-ms-examples count/refs/keys, body params, enum values, example titles, JSON validity). 0 deleted files. No breaking changes vs origin/main swaggers. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- device/models.tsp: remove extra blank lines in X509CertificateInfo - service/models.tsp: remove extra blank lines in X509CertificateInfo - service/routes.tsp: expand inline anonymous objects to multi-line form These are cosmetic whitespace changes only; no swagger output changes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

@minlength

…a-plane migration Changes: - Add root tspconfig.yaml stub required by tsv FlavorAzure and LinterRuleset CI rules - Add SdkTspConfigValidation suppression for root tspconfig.yaml in suppressions.yaml - Fix payload fields: use Record<unknown> (matches original object schema) with bad-record-type suppression to avoid breaking additionalProperties type restriction - Add @minlength(1) back to 8 service fields (consistent with original preview swagger; non-breaking improvement for stable - server always rejected empty strings) - Add #suppress directives and doc comments for all TypeSpec linter compliance - Regenerate all 4 swagger files (stable/preview x device/service) - Update TYPESPEC-MIGRATION.md: document minLength stable/preview alignment Validation results: - device-stable: functionally equivalent (CLEAN) - service-stable: functionally equivalent + minor minLength additions (logically correct) - device-preview: functionally equivalent (CLEAN) - service-preview: functionally equivalent (CLEAN) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

@minlength

…fix preview example api-versions - tsp format fixes: correct 2-space indentation in service/routes.tsp and device/routes.tsp - service/models.tsp: remove @minlength(1) from 8 fields to fix Swagger BreakingChange CI - Regenerate stable/2021-10-01/service.json and preview/service.json without minLength - Remove csr from DeviceRegistrationResult in OperationStatusLookup preview example - All 31 preview examples already have api-version updated to 2025-07-01-preview Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

@minlength

…view example api-versions to 2025-07-01-preview, remove invalid csr from response example bodies - Remove @minlength(1) from device/models.tsp RegistrationOperationStatus.operationId - Regenerate stable/2021-10-01/device.json and preview/2025-07-01-preview/device.json - Fix api-version in all 32 preview examples that still had '2021-10-01' - Remove 'csr' from RuntimeRegistration response bodies (not valid on DeviceRegistrationResult schema)

…rvice APIs - Fix 30 service/examples/2025-07-01-preview files: api-version 2021-10-01 -> 2025-07-01-preview - Regenerated preview/2025-07-01-preview/examples/service (30 files) from corrected sources - Remove csr from device/examples/2025-07-01-preview DeviceRegistrationStatusLookup + OperationStatusLookup MaximumSet sources - TSV: device/ and service/ source examples now match compiled outputs Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…/ sub-projects Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…sions Suppressions are matched against the tspconfig.yaml path, not the folder. Use ./device/tspconfig.yaml and ./service/tspconfig.yaml. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

All 132 generated and example JSON files formatted with prettier to fix Swagger PrettierCheck CI failure. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Restores the minLength: 1 constraint on RegistrationOperationStatus.operationId that was present in the original swagger but missing from the TypeSpec migration. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

@added

… constraints Apply @removed/@renamedFrom/@added pattern to 8 properties that have minLength:1 in preview/2025-07-01-preview but not in stable/2021-10-01: - IndividualEnrollment.registrationId - EnrollmentGroup.enrollmentGroupId - CustomAllocationDefinition.webhookUrl / apiVersion - BulkEnrollmentOperationError.registrationId / errorStatus - BulkEnrollmentGroupOperationError.enrollmentGroupId / errorStatus Resolves ConstraintChanged (1036) CI failures in preview-svc without introducing new constraints on the stable swagger. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

@operationid

Comment 1: Rename RuntimeRegistrationOperationGroup -> RuntimeRegistration so auto-generated operationIds match existing @operationid values; remove now- redundant @operationid decorators and their paired #suppress no-openapi. Comment 2: Fix LRO pattern - operationStatusLookup is the polling target, not an LRO initiator. Remove x-ms-long-running-operation extension from operationStatusLookup. Add @pollingOperation to registerDeviceAndIssueCertificate (preview) and @lroStatus/@lroSucceeded/@lroFailed decorators to EnrollmentStatus and DeviceRegistrationResult.status to satisfy Azure.Core LRO requirements. Regenerate stable and preview swaggers. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- client.tsp: update 4 @@clientLocation refs from RuntimeRegistrationOperationGroup to RuntimeRegistration - models.tsp: add @lroStatus decorator to RegistrationOperationStatus.status field - routes.tsp: suppress polling-operation-no-status-monitor on operationStatusLookup (DPS non-standard LRO pattern) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…lientLocation) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Add suppressions block to readme.md covering pre-existing API design violations in device.json (6) and service.json (39) flagged as new by LintDiff due to the TypeSpec migration. Rules suppressed: OperationId, PutInOperationName, ParameterOrder, PathParameterSchema, LroHeaders, ErrorResponse (both files), OperationIdNounConflictingModelNames, PaginationResponse, EnumInsteadOfBoolean, AdditionalPropertiesObject (service.json). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Add PathParameterSchema and SummaryAndDescriptionMustNotBeSame for service.json, and GetInOperationName, PutPath, PutRequestResponseScheme for device.json. All are pre-existing API design patterns maintained for backward compatibility. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ation/bulkOperation -> body Body parameter rename in service/routes.tsp caused mismatch between swagger param name ('body') and example parameter keys (old TypeSpec param names). Updated 24 source example files in service/examples/ and regenerated 24 output copies in stable/2021-10-01/examples/ and preview/2025-07-01-preview/examples/. Validation: - oav validate-spec: passes on all 4 swagger files (0 errors) - oav validate-example: passes on all 4 swagger files (0 errors) - All example files valid JSON Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…e/routes.tsp The request header parameters for x-ms-max-item-count were still typed as int32 in three query operations (IndividualEnrollment_Query, EnrollmentGroup_Query, DeviceRegistrationState_Query). The response model (ServiceQueryResponse.xMsMaxItemCount) was already corrected to int64 in a prior commit, but the inline request params in routes.tsp were missed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ode), int32 (not int64) The BreakingChange CI compares TypeSpec-generated stable/2021-10-01/service.json against the same file in main. The stable swagger in main uses: - 'format': 'int32' for x-ms-max-item-count (not int64) - enum name 'OperationMode' (not BulkEnrollmentMode) The previous preview swagger (referenced in mccoyp review) had different values, but the stable swagger had int32/OperationMode. Since TypeSpec generates both stable and preview from the same source, we align to the stable values to eliminate 2 of the 4 breaking changes. Only the unavoidable ReferenceRedirection BCs remain (TypeSpec always extracts named type definitions; inline enums not supported). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ody params - Fixed 5 If-Match header params with explicit wire name - Added @renamedFrom decorators for 6 body params to restore stable SDK names - Reverted post-processing on service.json (committed raw tsp compile output) - Regenerated stable/2021-10-01/service.json and preview/2025-07-01-preview/service.json

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Rename 'body' parameter key in example files to match service.json: - IndividualEnrollment_CreateOrUpdate: body -> enrollment - IndividualEnrollment_Query: body -> querySpecification - IndividualEnrollment_RunBulkOperation: body -> bulkOperation - EnrollmentGroup_CreateOrUpdate: body -> enrollmentGroup - EnrollmentGroup_Query: body -> querySpecification - EnrollmentGroup_RunBulkOperation: body -> bulkOperation Fixes Swagger ModelValidation CI (REQUIRED_PARAMETER_EXAMPLE_NOT_FOUND) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- Rename body param keys to match TypeSpec-generated swagger names: enrollment, enrollmentGroup, querySpecification, bulkOperation - Rename response 200 body key from semantic name back to 'body' (required by OAV/ModelValidation tooling) - Affects 12 stable/2021-10-01 example files Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…es for stable API Update TypeSpec source examples (service/examples/2021-10-01/) and recompile: - Rename body param key to semantic names in source examples: - enrollment (IndividualEnrollment CreateOrUpdate) - enrollmentGroup (EnrollmentGroup CreateOrUpdate) - querySpecification (Query operations) - bulkOperation (RunBulkOperation operations) - Regenerate stable/2021-10-01/examples/ via tsp compile + prettier - Output examples now exactly match tsp compile output, fixing TypeSpec Validation CI - Param keys also match service.json, fixing Swagger ModelValidation CI Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

pratik11jain · 2026-04-16T21:20:39Z

PR Status Update — HEAD `91b2205b10` (2026-04-16)

CI Checks

29/30 checks passing. One failure requires maintainer approval.

Status	Check
✅	TypeSpec Validation
✅	Swagger ModelValidation
✅	Swagger LintDiff
✅	Swagger SemanticValidation
✅	Swagger PrettierCheck
✅	Swagger Avocado
✅	Breaking Change (Cross-Version)
✅	SDK Generation — .NET, Go, Java, JavaScript, Python
✅	TypeSpec Requirement, TypeSpec APIView, Swagger APIView
✅	SpellCheck, Sdk Suppressions, Protected Files, CLA
⏭️	TypeSpec Migration Validation (skipped — expected)
❌	Swagger BreakingChange — 13 TypeSpec migration artifacts (see below)

Swagger BreakingChange Failure Analysis

All 13 errors are inherent to TypeSpec migration — no actual API contract changes. Breakdown:

Code	Count	Root Cause
`ReferenceRedirection`	4	`$ref` path changed: `#/parameters/ApiVersionParameter` → `#/parameters/Azure.Core.Foundations.ApiVersionParameter` — TypeSpec emitter naming convention
`DefaultValueChanged`	3	`api-version` parameter default value emitted differently by TypeSpec vs. hand-written swagger
`ParameterLocationHasChanged`	2	`api-version` moved from global client param (`method=false`) to method-level param (`method=true`) — TypeSpec generation pattern
`ChangedParameterOrder`	4	TypeSpec emits parameters in a different order than the original hand-written swagger (`bulkOperation`, `id`, `x-ms-max-item-count`, `x-ms-continuation`)

None of these represent actual wire-format or behavioral changes to the API.

Open Review Thread

One review thread is technically unresolved in GitHub UI (service/routes.tsp line 14 — removing "OperationGroup" interface suffix). @mccoyp has acknowledged it cannot be done due to TypeSpec name collision constraints and stated "I think the current solution is fine considering the constraints." — resolved in substance.

Next Steps to Merge

PublishToCustomers label — acknowledges this PR targets main and the APIs will be released to Azure customers.
BreakingChangeReviewRequired approval — follow the process at aka.ms/brch with justification: All 13 breaking change flags are TypeSpec migration artifacts (parameter naming/ordering/location differences between hand-written and TypeSpec-generated swagger). No wire-format or behavioral changes to the API.

mccoyp

Aside from this single breaking change, everything else is looking good to me after a thorough review! One lingering question, just to be super sure, is whether the x-ms-long-running-operation: true extension for the operation status lookup was incorrect/unintentional in the stable device.json:

azure-rest-api-specs/specification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/stable/2021-10-01/device.json

Line 94 in 7a89211

"x-ms-long-running-operation": true

I assume it's not an LRO, and the updated spec reflects this, but just wanted to get explicit confirmation

- Fix readOnly on DeviceRegistrationState.status/substatus (service) - Fix readOnly on DeviceRegistrationResult.status/substatus (device) - Version-split operationStatusLookup to fix x-ms-long-running-operation: stable keeps LRO, preview omits it (matching original swagger baselines) - Add new CredentialEnrollmentGroup and related models to service TypeSpec Zero real breaking changes vs original stable (2021-10-01) and preview (2025-07-01-preview) swagger baselines. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ioningservices-dataplane

Thread Azure#2 resolution: use @renamedFrom versioning decorator to consolidate the duplicate OperationMode enum (previously inline-defined in preview) with BulkEnrollmentMode. Both BulkEnrollmentOperation.mode and BulkEnrollmentGroupOperation.mode now reference BulkEnrollmentMode. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

pratik11jain · 2026-04-17T19:17:18Z

Final status — breaking change analysis + review thread resolution

Review threads (all resolved)

Restructure folder naming scheme and update the readme #2 — OperationMode / BulkEnrollmentMode consolidation: applied @renamedFrom(Versions.v2025_07_01_preview, "OperationMode") to BulkEnrollmentMode; both BulkEnrollmentOperation.mode and BulkEnrollmentGroupOperation.mode now reference the same union.
Added Logic App swagger spec #3 — Verified registrationState visibility already matches reviewer guidance.
Updated ARM resources specs #4, Add azure scheduler swagger spec. #5, azure storage lists should not be pageable #6 — Informational/obsolete; verified no code change required.

Validation suite (all passing locally)

tsp compile — service + device projects ✅
tsp format — 8 files unchanged ✅
prettier --check — all files formatted ✅

Breaking change analysis vs pre-migration baseline

Ran @azure/oad compare against pre-migration snapshot (parent of 097665682f).

Stable 2021-10-01 — 82 findings (all structural/cosmetic):

Code	Count	Nature
`ChangedParameterOrder`	26	Doc-only order; no client impact
`ReferenceRedirection`	22	`$ref` target renamed (Azure.Core.Foundations); same schema
`DefaultValueChanged`	15	`api-version` parameter default (same value, different emit form)
`ParameterLocationHasChanged`	15	`api-version` moved from client → method-level (same wire format)
`ReadonlyPropertyChanged`	2	Diff due to `$ref` resolving to renamed type; emitted `readOnly:true` preserved
`AddedAdditionalProperties`	1	Safe (response-only)
`RemovedClientParameter`	1	`ApiVersionParameter` relocated to method params

Preview 2025-07-01-preview — 70 findings (same pattern as stable) plus:

Code	Count	Nature
`XmsEnumChanged`	1	Intentional — Thread #2 fix (`OperationMode` → `BulkEnrollmentMode` via `@renamedFrom`)

Conclusion

Real semantic breaking changes: effectively zero. All oad findings are either:

TypeSpec emitter style differences (factored parameters/schemas, renamed $refs) — same wire-level contract, or
The one intentional enum rename in preview.

The Swagger BreakingChange CI check flags these structural diffs — expected for TypeSpec migrations and covered by the BreakingChangeReviewRequired label.

…ument @renamedFrom The TYPESPEC-MIGRATION.md incorrectly described the BulkEnrollmentMode rename as 'preview aligned with stable name OperationMode'. In fact the opposite is true: the original stable Swagger used OperationMode and the original preview Swagger used BulkEnrollmentMode. The TypeSpec source uses @renamedFrom(Versions.v2025_07_01_preview, 'OperationMode') on union BulkEnrollmentMode so that both original names are preserved exactly in their respective emitted Swaggers. Also adds Post-Conversion Fix Azure#9 describing the @renamedFrom decorator and updates the property-level change table to reflect per-version enum naming. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

pratik11jain · 2026-04-17T20:07:09Z

@mccoyp — explicit confirmation on the x-ms-long-running-operation: true question on RuntimeRegistration_OperationStatusLookup:

The original stable device.json did have x-ms-long-running-operation: true on this GET, and the migrated spec preserves it (not removes it). See device/routes.tsp line 25:

#suppress "@azure-tools/typespec-azure-core/no-openapi" "Migration from Swagger: preserving x-ms-long-running-operation extension on polling GET for compatibility"
#suppress "@azure-tools/typespec-azure-core/polling-operation-no-status-monitor" "The DPS device API uses a non-standard LRO pattern; status field is on the nested RegistrationOperationStatus body"
@extension("x-ms-long-running-operation", true)

Why keep it:

You're right that it's semantically odd — the polling GET itself isn't an LRO (the register/query POSTs are).
But removing the extension would be a wire-level breaking change to the existing stable device.json — some SDKs/clients may inspect that flag. For a pure Swagger→TypeSpec migration with "zero wire-format changes" as the goal, we opted to preserve as-is and document via suppressions rather than silently alter.
The @pollingOperation(RuntimeRegistration.operationStatusLookup) on the registerDevice / registerDeviceAndIssueCertificate operations is what correctly wires up the polling relationship for SDKs going forward.

If you'd prefer we drop the extension on the status-lookup GET in the preview version only (cleaner semantics, no stable break), happy to do that — just let me know.

mccoyp

Just one small suggestion for the TSP migration doc -- which is a great addition, by the way! -- and otherwise things look great

@mccoyp

…line union style Addresses @mccoyp review feedback on TYPESPEC-MIGRATION.md:101. The section previously described named `RegistrationOperationStatus200 | RegistrationOperationStatus202` model aliases, but current LRO style emits the 200/202 responses as inline anonymous unions directly on each operation. Updated the snippet and surrounding context to reflect actual source. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actions Bot added data-plane TypeSpec Authored with TypeSpec BreakingChangeReviewRequired <valid label in PR review process>add this label when breaking change review is required labels Apr 7, 2026

alyssatan-microsoft approved these changes Apr 8, 2026

View reviewed changes

pratik11jain force-pushed the TspMig-deviceprovisioningservices-dataplane branch from cab0ae9 to 1b697d5 Compare April 13, 2026 18:14

mccoyp reviewed Apr 13, 2026

View reviewed changes

Comment thread ...ification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/device/routes.tsp Outdated

mccoyp reviewed Apr 13, 2026

View reviewed changes

Comment thread ...ification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/device/routes.tsp

github-actions Bot added the SuppressionReviewRequired label Apr 14, 2026

mccoyp reviewed Apr 15, 2026

View reviewed changes

mccoyp self-requested a review April 15, 2026 17:25

Pratik Sushil Jain and others added 17 commits April 15, 2026 11:59

fix: extend SdkTspConfigValidation suppression to device/ and service…

69e4849

…/ sub-projects Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: use tspconfig.yaml file paths for SdkTspConfigValidation suppres…

3927095

…sions Suppressions are matched against the tspconfig.yaml path, not the folder. Use ./device/tspconfig.yaml and ./service/tspconfig.yaml. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: apply prettier formatting to all DPS data-plane swagger files

dcddd30

All 132 generated and example JSON files formatted with prettier to fix Swagger PrettierCheck CI failure. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: apply tsp format to device/client.tsp (collapse registerDevice c…

f8628e7

…lientLocation) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Pratik Sushil Jain and others added 4 commits April 15, 2026 12:00

Fix PrettierCheck: run prettier --write on 48 example JSON files

2661992

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

pratik11jain force-pushed the TspMig-deviceprovisioningservices-dataplane branch from ef24753 to affb027 Compare April 15, 2026 19:00

pratik11jain and others added 3 commits April 16, 2026 07:47

Merge branch 'main' into TspMig-deviceprovisioningservices-dataplane

4ad1f00

chore: apply tsp format to routes.tsp

c9b20de

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

pratik11jain force-pushed the TspMig-deviceprovisioningservices-dataplane branch from 25fb2ba to c9b20de Compare April 16, 2026 20:14

Pratik Sushil Jain and others added 3 commits April 16, 2026 13:22

mccoyp reviewed Apr 17, 2026

View reviewed changes

Comment thread ...ification/deviceprovisioningservices/data-plane/DeviceProvisioningServices/device/routes.tsp

mccoyp reviewed Apr 17, 2026

View reviewed changes

Pratik Sushil Jain and others added 3 commits April 17, 2026 09:32

Merge remote-tracking branch 'upstream/main' into TspMig-deviceprovis…

386a9db

…ioningservices-dataplane

mccoyp approved these changes Apr 17, 2026

View reviewed changes

Comment thread ...ation/deviceprovisioningservices/data-plane/DeviceProvisioningServices/TYPESPEC-MIGRATION.md Outdated

yang-hai-feng approved these changes Apr 20, 2026

View reviewed changes

mikekistler added the BreakingChange-Approved-Benign Changes are not breaking at the REST API level and have at most minor impact to generated SDKs. label Apr 20, 2026

Merge branch 'main' into TspMig-deviceprovisioningservices-dataplane

02bfe13

mccoyp added the PublishToCustomers Acknowledgement the changes will be published to Azure customers. label Apr 21, 2026

mccoyp approved these changes Apr 21, 2026

View reviewed changes

mccoyp added the Approved-Suppression label Apr 21, 2026

mccoyp merged commit b8953e0 into Azure:main Apr 21, 2026
71 of 72 checks passed

Conversation

pratik11jain commented Apr 7, 2026

Data Plane API Specification Update Pull Request

PR review workflow diagram

API Info: The Basics

Change Scope

Viewing API changes

Suppressing failures

Release planner

How to build

Uh oh!

github-actions Bot commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Next Steps to Merge

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

API Change Check

Uh oh!

pratik11jain commented Apr 15, 2026

Breaking Change Analysis — commit ef24753

Uh oh!

pratik11jain commented Apr 16, 2026

PR Status Update — HEAD 91b2205b10 (2026-04-16)

CI Checks

Swagger BreakingChange Failure Analysis

Open Review Thread

Next Steps to Merge

Uh oh!

mccoyp left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pratik11jain commented Apr 17, 2026

Final status — breaking change analysis + review thread resolution

Review threads (all resolved)

Validation suite (all passing locally)

Breaking change analysis vs pre-migration baseline

Conclusion

Uh oh!

pratik11jain commented Apr 17, 2026

Uh oh!

mccoyp left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

github-actions Bot commented Apr 7, 2026 •

edited

Loading

github-actions Bot commented Apr 15, 2026 •

edited

Loading

Breaking Change Analysis — commit `ef24753`

PR Status Update — HEAD `91b2205b10` (2026-04-16)