[AutoPR @azure-arm-mysql-flexible]-generated-from-SDK Generation - JS-6363402

[azure-sdk]

Configurations: 'specification/mysql/resource-manager/Microsoft.DBforMySQL/FlexibleServers/tspconfig.yaml', and CommitSHA: '3777e08b3bbee8bbaa26947169788dbdc4dd3a2a' in SpecRepo: 'https://github.com/Azure/azure-rest-api-specs' Pipeline run: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=6363402 Refer to https://eng.ms/docs/products/azure-developer-experience/develop/sdk-release/sdk-release-prerequisites to prepare for SDK release.

[github-actions]

Next Steps to Merge

Only failed checks and required actions are listed below.

• ⏳ js - pullrequest (Build UnitTest ubuntu_24x_node): still running.
• ⏳ js - pullrequest (Build UnitTest macoslatest_26x_node): still running.
• ⏳ js - pullrequest (Build UnitTest windows_22x_node): still running.
• ⏳ js - pullrequest (Build UnitTest windows_22x_browser): still running.

i️ This PR is currently a draft. Once CI passes and the PR is ready, convert it to "Ready for review" to enable merge.

[github-actions]

No API design issues found. The @azure/arm-mysql-flexible 4.0.0-beta.5 package looks good: version is consistent across package.json, CHANGELOG.md, and the context file; KnownVersions correctly retains the stable 2024-12-30 and adds the new 2025-06-01-preview api-version; no naming anti-patterns (_N, AutoGenerated), no unknown types outside allowed, no void returns on CRUD operations, and no client name changes.

📊 Structured Report

{"agent":"mgmt-reviewer","pr":38715,"summary":"clean","findings":[]}

⚡ Benchmarked by Management Release Assistant

[kazrael2119]

Breaking Change Analysis: @azure/arm-mysql-flexible — PR #38715

Package version: 3.1.0 (stable, AutoRest/HLC) → 4.0.0-beta.5 (TypeSpec modular emitter)
API version: 2023-12-30 → 2024-12-30
Total breaking changes reported: 10 (compared with stable 3.1.0)
Spec commit (Layer C): 3777e08b3bbee8bbaa26947169788dbdc4dd3a2a

---

Summary

Classification	Count	Description
Type 1	0	No true API version regressions
Type 2a	5	TypeSpec conversion — ARM common-types version upgrade
Type 2b	5	AutoRest HLC emitter artifacts (model deduplication, naming conflicts)
Total	10

---

Type 1 — True API Version Changes (0)

None. The API version did advance from 2023-12-30 to 2024-12-30, but this upgrade introduced new operations and models only — no removal of types or properties that were present in the old API version.

---

Type 2a — TypeSpec Conversion Artifacts, API-equivalent (5)

These changes stem from the TypeSpec project adopting ARM common-types v5, which restructures the error response schema. The underlying REST API wire format is unchanged; only the SDK representation of error responses differs.

ErrorResponse — ARM common-types v1 → v5 error schema restructuring (5 entries)

Root cause: AutoRest HLC auto-injected the ARM common-types v1 ErrorResponse type with five direct properties. TypeSpec explicitly uses @azure-tools/typespec-azure-resource-manager's common-types v5, where ErrorResponse wraps these properties in an ErrorDetail sub-object. Neither the Layer A swagger files (package-flexibleserver-2023-12-30) nor the Layer C swagger (2024-12-30/openapi.json) define ErrorResponse locally — they both rely on the error type from their respective ARM common-types library. The structural change is caused by the TypeSpec project choosing common-types v5.

CHANGELOG entry	Old ErrorResponse (3.1.0 HLC, common-types v1)	New ErrorResponse (4.0.0-beta.5, common-types v5)
Interface ErrorResponse no longer has parameter additionalInfo	readonly additionalInfo?: ErrorAdditionalInfo[]	Property moved to ErrorDetail
Interface ErrorResponse no longer has parameter code	readonly code?: string	Property moved to ErrorDetail
Interface ErrorResponse no longer has parameter details	readonly details?: ErrorResponse[]	Property moved to ErrorDetail
Interface ErrorResponse no longer has parameter message	readonly message?: string	Property moved to ErrorDetail
Interface ErrorResponse no longer has parameter target	readonly target?: string	Property moved to ErrorDetail

Migration path: Access error properties via error.error?.code, error.error?.message, etc. The ErrorDetail interface in the new SDK exposes all the same fields.

---

Type 2b — AutoRest HLC Emitter Artifacts (5)

These changes have no impact on REST API semantics. They are direct side-effects of the AutoRest HLC (High-Level Client) emitter being replaced by the TypeSpec modular emitter.

CloudError removed — AutoRest HLC auto-generated ARM error envelope (1 entry)

Root cause: AutoRest HLC with the --azure-arm flag automatically generated a CloudError { error?: ErrorResponse } wrapper type for every ARM SDK. This type is not defined in any Layer A swagger file and is not produced by the TypeSpec modular emitter. The modular emitter uses ErrorResponse { error?: ErrorDetail } as the top-level error type directly. CloudError was never referenced by any operation signature in the 3.1.0 SDK and had zero API functionality.

CHANGELOG entry	✅ Pattern
Removed Interface CloudError	AutoRest HLC emitter auto-inject artifact

Sku removed — AutoRest HLC model deduplication (1 entry)

Root cause: The Layer A swagger (FlexibleServers.json@2023-12-30) defines MySQLServerSku { name: string, tier: ServerSkuTier }. AutoRest HLC was invoked with --modelerfour.lenient-model-deduplication, which merges structurally-equivalent models. This caused MySQLServerSku to be deduplicated into the ARM generic Sku type. The TypeSpec modular emitter preserves the precise name MySQLServerSku.

CHANGELOG entry	Layer A swagger name	3.1.0 HLC SDK name	4.0.0-beta.5 TypeSpec SDK name
Removed Interface Sku	MySQLServerSku	Sku (deduplicated)	MySQLServerSku (preserved)

Storage_2 removed — AutoRest HLC naming conflict artifact (1 entry)

Root cause: The Layer A swagger defines Storage { storageSizeGB, iops, autoGrow, storageSku }. AutoRest HLC could not export this as Storage because that name conflicted with another type in the generated SDK. HLC renamed the internal type to Storage_2 and re-exported it as export { Storage_2 as Storage }. The TypeSpec modular emitter resolves this cleanly by exporting export interface Storage directly (same behavior seen in Global_2 → Global pattern in other ARM SDKs).

CHANGELOG entry	3.1.0 HLC SDK name	4.0.0-beta.5 TypeSpec SDK name
Removed Interface Storage_2	interface Storage_2 + export { Storage_2 as Storage }	export interface Storage

SkuTier and KnownSkuTier removed — AutoRest HLC model deduplication (2 entries)

Root cause: The Layer A swagger defines MySQLServerSku.tier with x-ms-enum: { name: "ServerSkuTier", modelAsString: true } — confirming the intended enum name is ServerSkuTier. AutoRest HLC's --modelerfour.lenient-model-deduplication renamed the enum type from ServerSkuTier to the ARM generic SkuTier (same as the deduplication of MySQLServerSku → Sku). The TypeSpec modular emitter restores the correct name ServerSkuTier and KnownServerSkuTier.

CHANGELOG entry	Layer A x-ms-enum name	3.1.0 HLC SDK name	4.0.0-beta.5 TypeSpec SDK name
Removed Type Alias SkuTier	ServerSkuTier	SkuTier (deduplicated)	ServerSkuTier (preserved)
Removed Enum KnownSkuTier	ServerSkuTier	KnownSkuTier (deduplicated)	KnownServerSkuTier (preserved)

---

Conclusion

Of the 10 reported breaking changes:

• 0 are Type 1 — The API version upgrade from 2023-12-30 to 2024-12-30 did not remove any types or properties present in the previous version.
• 5 are Type 2a — The ErrorResponse property changes are caused by the TypeSpec project adopting ARM common-types v5 (modern wrapped error format) in place of the old AutoRest-injected common-types v1 (flat error format). These represent an ARM error schema evolution, not a service API regression.
• 5 are Type 2b — CloudError, Sku, Storage_2, SkuTier, and KnownSkuTier are all AutoRest HLC emitter artifacts: one auto-generated ARM envelope type, two cases of model deduplication via --modelerfour.lenient-model-deduplication (with cascading enum rename), and one naming-conflict workaround. None of these types correspond to actual swagger definitions; they were all synthetic constructs of the HLC pipeline.

All 10 breaking changes are SDK generation artifacts with no REST API regression.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.