[RecoveryServicesBackupCrr] New TypeSpec project for CRR, stable 2026-07-15 - #44457
Open
bharatpurwar wants to merge 17 commits into
Open
[RecoveryServicesBackupCrr] New TypeSpec project for CRR, stable 2026-07-15#44457bharatpurwar wants to merge 17 commits into
bharatpurwar wants to merge 17 commits into
Conversation
…01-15 Swagger (raw converter output) Create a new TOP-LEVEL service folder specification/recoveryservicesbackupcrr/ for the passive-stamp Cross-Region-Restore (CRR) surface, and bootstrap a dedicated TypeSpec project by converting the legacy hand-authored stable/2023-01-15/bms.json. - New folder: recoveryservicesbackupcrr/resource-manager/Microsoft.RecoveryServices/RecoveryServicesBackupCrr/ - Generated via: npx tsp-client convert --arm --fully-compatible (from 2023-01-15 CRR bms.json) - Files (raw converter output, NOT yet customized): main.tsp, models.tsp (119 models / 27 unions / 3 enums), routes.tsp (8 CRR operation groups), RecoveryPointResource.tsp, BackupResourceConfigResource.tsp, back-compatible.tsp, tspconfig.yaml, and examples/2023-01-15/ (18 example JSONs). This is a bootstrap-only checkpoint. Still TODO (next commits): retarget to stable version 2026-07-15, CRR-specific SDK package names, route/casing/pageable/odata/response-code fidelity fixes, common-types v6, lint config, and the WorkloadCrrAccessToken MSI model change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Step 3 of the CRR (cross-region-restore) TypeSpec migration into the new top-level specification/recoveryservicesbackupcrr/ project. Source changes only; the generated stable/2026-07-15/ swagger output (bms.json + emitted example copies) is intentionally NOT committed yet. main.tsp: - Versions enum -> single stable v2026_07_15: "2026-07-15" - real @doc service description - @service title "Recovery Services Backup CRR Client" - @armCommonTypesVersion CommonTypes.Versions.v6 tspconfig.yaml: - replaced with mirrored ARM emitter config - distinct ...crr SDK package names (Azure.ResourceManager.RecoveryServicesBackupCrr, azure-mgmt-recoveryservicesbackupcrr, azure-resourcemanager-recoveryservicesbackupcrr, @azure/arm-recoveryservicesbackupcrr, armrecoveryservicesbackupcrr) examples: - moved examples/2023-01-15 -> examples/2026-07-15 and retagged api-version Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Next Steps to MergeNext steps that must be taken to merge this PR:
Comment generated by summarize-checks workflow run. |
API Change CheckAPIView identified API level changes in this PR and created the following API reviews
Comment generated by After APIView workflow run. |
Re-applies the fidelity fixes needed so the emitted swagger faithfully reproduces the frozen 2023-01-15 CRR contract. Ported from the prior sub-folder branch (same converter 0.11.14, same source, identical repo depth) and verified against the 2023-01-15 baseline. Generated stable/2026-07-15/ output (bms.json + emitted example copies) is intentionally NOT committed yet. VirtualResource.tsp (new): - Adds the @armVirtualResource signpost chain Vault -> BackupFabric -> ProtectionContainer -> ProtectedItemVirtual used to rebuild the deep CRR resource URLs. main.tsp: - import "./VirtualResource.tsp". RecoveryPointResource.tsp: - @parentResource(ProtectedItemVirtualResource) to restore the full deep path (vaults/.../protectedItems/.../recoveryPoints/...) that the converter had flattened (+ beyond-nesting-levels suppress). - TrackedResourceWithOptionalLocation -> ProxyResource; re-add optional location + ArmTagsProperty envelope fields to match original wire shape. - Restore x-ms-pageable (nextLink) and x-ms-odata (BMSRPQueryObject) on RecoveryPointsCrr_List. - Restore documented 400 on RecoveryPoints_GetAccessToken via new AccessTokenBadRequestResponse (@error, statusCode 400) added to the response union. BackupResourceConfigResource.tsp: - Tracked -> ProxyResource for the vaultstorageconfig singleton; explicit @operationid overrides preserving legacy ids (BackupResourceStorageConfigs_Get/_Update/_patch). routes.tsp / models.tsp: - BMSAAD/BMSRP acronym casing restored (BMSAADPropertiesQueryObject, BMSRPQueryObject). - CRR job / cross-region-restore ops kept faithful (header-less 202, body param naming, LRO extensions); legacy model Resource {} base kept (wire-identical to 2023-01-15, no systemData) rather than migrated. tspconfig.yaml: - Add linter.disable block with per-rule backward-compat justifications (casing-style, no-string-discriminator, no-multiple-discriminator, missing-x-ms-identifiers, documentation-required, lro-location-header, no-empty-model, arm-post-operation-response-codes, missing-operations-endpoint, no-resource-delete-operation, no-response-body). Verified vs 2023-01-15 baseline: 12/12 paths, 14/14 operationIds, 120/120 original definitions present (0 missing); compiles clean with tsp compile --warn-as-error (0 errors, 0 warnings). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The example set protectedItemType to "Microsoft.ClassicCompute/virtualMachines", which is a grandchild discriminator value (AzureIaaSClassicComputeVMProtectedItem -> AzureIaaSVMProtectedItem -> ProtectedItem). oav resolves the base ProtectedItem.protectedItemType discriminator, where only direct-child values are registered, so the grandchild value fails with DISCRIMINATOR_VALUE_NOT_FOUND. Set it to the valid direct-child "AzureFileShareProtectedItem" (CRR's primary workload). Examples are illustrative, not part of the wire contract, so this does not change the API. Fixes oav validate-example for BackupProtectedItemsCrr_List. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Prettier normalization of the 2026-07-15 CRR example files to satisfy the repo Prettier check. Formatting-only; no content or contract changes. (The BackupProtectedItems_List discriminator value fix is in the previous commit; generated stable/ output remains uncommitted.) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The converter did not carry @tag decorators, so emitted operations either had no tag (the routes.tsp provider-action ops) or inherited the TypeSpec interface name as the tag (RecoveryPointResources, BackupResourceConfigResources) instead of the original 2023-01-15 tag values. Restore all 14 operation tags to match the frozen original. routes.tsp: - Add interface-level @tag to the 8 operation groups: BackupUsageSummaries_CRR, AadProperties, CrossRegionRestore, CrrJobDetails, BackupCrrJobs, CrrOperationResults, CrrOperationStatus, BackupProtectedItems_Crr. BackupResourceConfigResource.tsp: - Add interface-level @tag("BackupResourceStorageConfigs") (covers get/update/patch). RecoveryPointResource.tsp: - Add interface-level @tag("RecoveryPoints_Crr") to RecoveryPointResources (covers get/list). Interface-level @tag overrides the auto interface-name tag; op-level @tag would instead append and duplicate it. - Split getAccessToken into its own interface RecoveryPointGetAccessToken with @tag("RecoveryPoints_GetAccessToken"), since it needs a different tag than its siblings. back-compatible.tsp: - Update @@clientLocation / @@clientName references from RecoveryPointResources.getAccessToken to RecoveryPointGetAccessToken.getAccessToken. Verified: emitted tags now match the original 2023-01-15 for all 14 operations; compiles clean with --warn-as-error; paths/ops/definitions unchanged (12/14/158); oav validate-example passes. Generated stable/ output remains uncommitted. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…o 2023-01-15) The Step 4 pageable fix re-added x-ms-pageable uniformly with nextLinkName: "nextLink" on all 4 CRR list operations. But the original 2023-01-15 spec used nextLinkName: null specifically for BackupUsageSummariesCRR_List, because its response model BackupManagementUsageList has only a 'value' property and no 'nextLink' (it is a non-continuable list). Our emitted value pointed at a nextLink property that does not exist. routes.tsp: - BackupUsageSummariesCRROperationGroup.list: @extension("x-ms-pageable", #{ nextLinkName: null }) to match the original. The other 3 list ops (BackupCrrJobs_List, RecoveryPointsCrr_List, BackupProtectedItemsCrr_List) keep "nextLink", matching the original. Verified: all 4 list ops' nextLinkName now match 2023-01-15 (0 mismatches); compiles clean with --warn-as-error; oav validate-example passes. Generated stable/ output remains uncommitted. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Commits the emitter output for the CRR (cross-region-restore) TypeSpec project: stable/2026-07-15/bms.json plus the 16 emitted example copies. This is the API contract artifact reviewers, Swagger LintDiff, and oav validate against. Generated by: npx tsp compile . (typespec-autorest emitter), then prettier --write on the emitted json. Faithful to the frozen 2023-01-15 CRR surface: 12 paths, 14 operations, all 120 original definitions present; operation tags, x-ms-pageable (incl. nextLinkName: null for BackupUsageSummariesCRR_List), x-ms-odata, and response codes matched to the original. Compiles clean with --warn-as-error; oav validate-example passes; prettier clean. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Addresses the validation failures on the CRR (cross-region-restore) spec PR. SpellCheck: - Add spec-local specification/recoveryservicesbackupcrr/cspell.yaml (imports the root config) allow-listing the new words that were flagged in the changed files: armrecoveryservicesbackupcrr, BMSAAD, BMSRP, recoveryservicesbackupcrr, Retriable, SQLAG, SQLDB, Undelete. (Pre-existing specs were never re-checked; only our new files trip the check.) Swagger Avocado (MISSING_README) and Swagger LintDiff (bms.json not found in specModel): - Add resource-manager/.../RecoveryServicesBackupCrr/readme.md (AutoRest config) with tag package-2026-07-15 referencing stable/2026-07-15/bms.json, so tooling can locate the emitted swagger. Kept minimal for a TypeSpec-first project (SDK generation is driven by tspconfig.yaml); suppressions to be added reactively once LintDiff can actually run. SDK Validation (.NET / Java / Python duplicate-client-name "Resource"): - back-compatible.tsp: add @@clientName(Resource, "CrrResource", "csharp,java,python,javascript,go"). Our legacy envelope model is named Resource (kept for wire-fidelity to the frozen 2023-01-15 swagger), which collides with the ARM common-types Resource in the SDK client scope. Rename it consistently across all generated SDK languages while excluding the autorest emitter, so the emitted swagger definition stays "Resource" (verified: bms.json unchanged, props id/name/type/location/tags/eTag intact). Not addressed here (governance gate): ARM Modeling Review requires an ARM lease granted via ARM API Modeling Office Hours; it is an approval artifact, not a code change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fixes found during a line-by-line diff review of the emitted swagger against the frozen 2023-01-15 CRR contract (tracked in files/crr-diff-review-issues.md). routes.tsp: - CrossRegionRestore_Trigger and CrrOperationResults_Get: replace the custom / ArmAcceptedResponse 202 with the built-in header-less AcceptedResponse (matches the sibling active-stamp). Removes a template-injected Retry-After header on CrrOperationResults (original 202 was header-less) and drops 2 orphan empty response definitions. (issues Azure#14, Azure#21) RecoveryPointResource.tsp: - Restore original path-param descriptions via @@doc (recoveryPointId -> "Recovery Point Id"). (issue Azure#15) - getAccessToken 400: inline anonymous response instead of a named @error model (per user request, removes the orphan definition). NOTE: this drops x-ms-error-response and the "BadRequest" description vs the original -- flagged for ARM/LintDiff review in the issues doc. (issue Azure#21 UPDATE 2) VirtualResource.tsp: - Restore original path-param descriptions via @@doc for vaultName / fabricName / containerName / protectedItemName (were auto-generated "The name of the X"). (issue Azure#15) models.tsp: - Enum-doc cleanup: strip the 178 redundant per-member doc comments (doc == member value) so emitted x-ms-enum.values carry no redundant description -- matches the active-stamp and eliminates all 178 DescriptionMustNotBeNodeName findings. (issue Azure#18) Full audit after these changes: 12/12 paths, 14/14 operationIds, 120/120 original definitions present (0 missing), 0 response headers anywhere (matches original). Compiles clean with --warn-as-error; tsp format + prettier clean. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
readme.md ## Suppression: directive block suppressing the error-level LintDiff rules that fire on the new swagger because they are pre-existing traits of the frozen 2023-01-15 CRR contract (legacy envelopes, response codes, path structure, tracked-resource false positives from legacy location/tags, header-less 202, no provider Operations list, etc.). Mirrors the sibling RecoveryServicesBackup readme. Note: DescriptionMustNotBeNodeName is intentionally NOT suppressed here -- the underlying 178 redundant enum-member docs were fixed at source (enum-doc cleanup), so the rule no longer fires. 23 directives total. MANDATORY before merge: re-audit this suppression list against the actual LintDiff output of the current commit and remove any suppression whose rule no longer fires (several underlying issues were fixed, not suppressed). Requires ARM/LintDiff reviewer sign-off. See files/crr-diff-review-issues.md. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions
Bot
added
package-name-review-required
Namespace Review RequiredPlane: Management Plane
How to approve:
Merge is blocked until all languages are approved. Approver list: .github/namespace-approvers.yml |
Two review-driven fidelity fixes (see files/crr-diff-review-issues.md): RecoveryPointResource.tsp (issue Azure#21 / LintDiff error): - Restore the named @error model AccessTokenBadRequestResponse for the RecoveryPoints_GetAccessToken 400. The earlier inline anonymous 400 dropped x-ms-error-response, which LintDiff flagged as MissingXmsErrorResponse (the only error-level violation). The named @error model emits {"description":"BadRequest","x-ms-error-response":true} - matching the frozen 2023-01-15 exactly and clearing the error. (The one small orphan empty definition is the unavoidable, faithful cost of emitting a 400 with x-ms-error-response.) routes.tsp (issue Azure#13 / SummaryAndDescriptionMustNotBeSame): - The 4 ops AadProperties_Get, CrossRegionRestore_Trigger, BackupCrrJobDetails_Get, BackupCrrJobs_List had both a doc comment (-> description) and @summary with the SAME text (converter duplicated it), tripping SummaryAndDescriptionMustNotBeSame. The frozen original had SUMMARY ONLY (no description). Removed the redundant doc comments, keeping @summary -> ops now emit summary-only, matching the original exactly and clearing the warning. Verified: compiles clean with --warn-as-error; prettier clean; 12/12 paths, 14/14 operationIds, 120/120 original definitions present. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fixes the intermediate-discriminator fidelity gap (issue Azure#20) across all three polymorphic trees (ProtectedItem / RecoveryPoint / RestoreRequest), 19 models: - The converter added @Discriminator to 8 INTERMEDIATE types, so TypeSpec treated them as abstract bases and emitted an EMPTY x-ms-discriminator-value plus a spurious required:[protectedItemType|objectType] - a genuine contract gap vs the frozen 2023-01-15 (a payload using an intermediate discriminator value would not validate against our spec). - Fix (mirrors the active-stamp 2025-01-01): declare every variant as a direct child of its @Discriminator ROOT with an explicit literal discriminator property (so each - including the intermediates - gets a concrete x-ms-discriminator-value and no child overrides a fixed literal), then re-establish the original nested allOf on the wire with @@hierarchyBuilding(child, parent) from Azure.ClientGenerator.Core.Legacy (18 directives, each with a no-legacy-usage suppression). Also (issue Azure#20 cosmetic sub-point): remove the redundant field doc on AzureIaaSVMProtectedItem.extendedProperties so the emitted property is \-only, matching the original (the ExtendedProperties model keeps its description). Verified: compiles clean with --warn-as-error; all 19 discriminated types byte-match the frozen 2023-01-15 (allOf + x-ms-discriminator-value + required + own-properties); global scan shows 0 defs with empty x-ms-discriminator-value (was 8); local LintDiff (azure-validator) reports 0 errors. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…DK renames Aligns the CRR project structure and SDK customizations with the active-stamp (RecoveryServicesBackup), and removes systemData for full 2023-01-15 fidelity. main.tsp: - @armCommonTypesVersion v6 -> v3 (matches the active-stamp's source). This makes the two real resources (BackupResourceConfigResource, RecoveryPointResource) emit via is ProxyResource<T> WITHOUT systemData while keeping correct resource URLs/operations - resolving issue Azure#22 (the frozen 2023-01-15 had no systemData). Verified: 0 systemData occurrences; resource paths intact. NOTE: v3 (not latest v6) is a deliberate faithfulness choice - flag for ARM-reviewer awareness. - import ./client.tsp. client.tsp (new - mirrors the active-stamp's file layout): - Holds SDK model-name customizations (moved out of back-compatible.tsp). - ErrorDetail renamed EXACTLY as the active-stamp (resolves the SDK duplicate-client-name with common-types ErrorDetail): @@clientName(Azure.ResourceManager.CommonTypes.ErrorDetail, "ArmErrorDetail"); @@clientName(ErrorDetail, "BackupErrorDetail", "csharp"); - Resource collision resolved with the same two-sided style: @@clientName(Azure.ResourceManager.CommonTypes.Resource, "ArmResource"); @@clientName(Resource, "CrrResource", "csharp"); back-compatible.tsp: - Now holds only wire/operation back-compat (@@hierarchyBuilding, @@clientLocation, parameter @@clientName); the Resource model rename moved to client.tsp. All @@clientName changes are SDK-client-only: the emitted swagger definitions remain "Resource"/"ErrorDetail" (wire stays byte-faithful). Verified: compiles clean with --warn-as-error; prettier clean; 19/19 discriminated types still byte-match 2023-01-15; LintDiff 0 errors. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ssion reasons Fidelity fix (models.tsp): - Add @extension("x-ms-azure-resource", true) to the legacy CRR Resource envelope. The frozen 2023-01-15 Resource sets x-ms-azure-resource:true, but our emitted spec had dropped it. Restoring it makes the emitted swagger byte-faithful to the original and clears the ResourceHasXMsResourceEnabled LintDiff error at the source (rather than suppressing it). Verified: emitted Resource now has x-ms-azure-resource:true; compiles clean; local LintDiff 0 errors. readme.md (suppression reasons): - Removed the ResourceHasXMsResourceEnabled suppression (now fixed at source; 23 -> 22). - Rewrote the remaining 22 suppression reasons to be operation/resource-specific and cite the exact LintDiff cause (which resource/operation trips each rule and why the frozen 2023-01-15 contract requires preserving it). Notable correction: the XmsPageableForListCalls reason previously named the wrong operation (BackupUsageSummariesCRR_List); the actual violator is AadProperties_Get (a collection-path singleton GET without x-ms-pageable). All changes verified: tsp compile --warn-as-error clean; readme YAML valid (22 directives); local LintDiff (azure-validator) 0 errors. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…improved suppression reasons The previous commit added @extension("x-ms-azure-resource", true) to the CRR Resource envelope to restore that marker. However that decorator emits DIFFERENTLY across TypeSpec compiler versions (local 1.13.0 vs the tsv/CI 1.14.0), so CI's TypeSpec-Validation "Compile" rule (which emits bms.json then git-diffs) saw drift and failed - a check that was green on the prior commit. - models.tsp: revert the @extension + @typespec/openapi import (back to the exact state of the last tsv-passing commit). bms.json is now byte-identical to that known-good output. - readme.md: re-add the ResourceHasXMsResourceEnabled suppression with an accurate reason (the frozen 2023-01-15 Resource sets x-ms-azure-resource, but emitting it here requires the compiler-version-fragile @extension; suppress rather than break TypeSpec Validation). All other 22 suppression reasons keep the review-driven, operation/resource-specific wording (including the XmsPageableForListCalls correction). Verified: models.tsp and stable/2026-07-15/bms.json are identical to the last tsv-passing commit; compiles clean; readme YAML valid (23 directives). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
CI's TypeSpec Validation (tsv) compiles with a pre-release compiler (1.14.0-dev) that emits an empty "description": "" for AadProperties_Get (which had @summary but no @doc), while the stable 1.13.0 that generates the committed spec omits it. The tsv Compile rule regenerates bms.json and git-diffs it, so this one-line drift failed the check. Fix: give AadProperties_Get an explicit @doc (distinct from its @summary). Both compiler versions now emit the same non-empty description, eliminating the drift. Summary and description are distinct, so SummaryAndDescriptionMustNotBeSame does not fire. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
bharatpurwar
marked this pull request as ready for review
July 17, 2026 04:05
bharatpurwar
added
the
PublishToCustomers
| arm-types-dir: "{project-root}/../../../../common-types/resource-management" | ||
| emit-lro-options: "all" | ||
| "@azure-typespec/http-client-csharp-mgmt": | ||
| namespace: "Azure.ResourceManager.RecoveryServicesBackupCrr" |
Member
There was a problem hiding this comment.
Consider using the namespace Azure.ResourceManager.RecoveryServicesBackup.CrossRegionRestore
| "@azure-tools/typespec-python": | ||
| service-dir: "sdk/recoveryservices" | ||
| emitter-output-dir: "{output-dir}/{service-dir}/azure-mgmt-recoveryservicesbackupcrr" | ||
| namespace: "azure.mgmt.recoveryservicesbackupcrr" |
Member
There was a problem hiding this comment.
Consider using the namespace azure.mgmt.recoveryservicesbackupcrossregionrestore
| emit-lro-options: "all" | ||
| "@azure-typespec/http-client-csharp-mgmt": | ||
| namespace: "Azure.ResourceManager.RecoveryServicesBackupCrr" | ||
| emitter-output-dir: "{output-dir}/sdk/recoveryservices-backup/Azure.ResourceManager.RecoveryServicesBackupCrr" |
Member
There was a problem hiding this comment.
value should be {output-dir}/sdk/recoveryservices-backup/{namespace}
| emitter-output-dir: "{output-dir}/sdk/recoveryservices-backup/Azure.ResourceManager.RecoveryServicesBackupCrr" | ||
| "@azure-tools/typespec-python": | ||
| service-dir: "sdk/recoveryservices" | ||
| emitter-output-dir: "{output-dir}/{service-dir}/azure-mgmt-recoveryservicesbackupcrr" |
Member
There was a problem hiding this comment.
the value should be {output-dir}/{service-dir}/azure-mgmt-recoveryservicesbackupcrossregionrestore
| flavor: "azure" | ||
| "@azure-tools/typespec-java": | ||
| emitter-output-dir: "{output-dir}/{service-dir}/azure-resourcemanager-recoveryservicesbackupcrr" | ||
| namespace: "com.azure.resourcemanager.recoveryservicesbackupcrr" |
Member
There was a problem hiding this comment.
Consider using the namespace com.azure.resourcemanager.recoveryservicesbackupcrossregionrestore
Member
There was a problem hiding this comment.
recoveryservicesbackupcrossregionrestore (40 chars) exceeds Java checkstyle's 32-char-per-segment limit
This part can be bypassed by setting ForceCreateEvenWithFailures=true in SDK generation pipeline, and then a suppression in SDK module.
But then there are more error on "path too long".
https://dev.azure.com/azure-sdk/public/_build/results?buildId=6601155&view=logs&j=b70e5e73-bbb6-5567-0939-8415943fadb9&t=74bd06c3-0f35-56f9-4379-f6be6cc8b9a5
Test spec #44884
Test sdk Azure/azure-sdk-for-java#49898
Member
Author
There was a problem hiding this comment.
Hi, in that case, should there be a name within 32 char limit only. Also, will this issue come for other sdks as well.
@ArthurMa1978
Member
There was a problem hiding this comment.
CRR is not a widely recognized acronym, so it should be expanded here. Unfortunately, doing so exceeds the length limit. I'm not sure whether removing "Backup" would be acceptable, as that would reduce the name to 34 characters. Or use 4-level namespace which will be com.azure.resourcemanager.recoveryservicesbackup.crossregionrestore?
Or do you have any alternative suggestions?
Member
There was a problem hiding this comment.
The "32-char-per-segment limit" can be suppressed.
But 4-level namespace has same effect on Java. It only slightly reduce the service folder from sdk/recoveryservicesbackupcrossregionrestore to sdk/recoveryservicesbackup -- save 18 char.
It would be too long for the limit on path.
Java requires namespace as path. So this line got doubled as 1. package name folder azure-resourcemanager-recoveryservicesbackup-crossregionrestore and 2. namespace paths com/azure/resourcemanager/recoveryservicesbackup/crossregionrestore; hence this alone takes 100+ chars
This is currently 257 -> it needs to be within 222
sdk/recoveryservicesbackupcrossregionrestore/azure-resourcemanager-recoveryservicesbackupcrossregionrestore/src/main/java/com/azure/resourcemanager/recoveryservicesbackupcrossregionrestore/implementation/RecoveryServicesBackupCrrManagementClientBuilder.java
Member
There was a problem hiding this comment.
If we use 4-level namespace, we still need lots of renames in Java
Here is agent's reply, not pretty...
RecoveryServicesBackupCrrManagementClientBuilder -> RsbCrrMgmtClientBuilder
BackupResourceStorageConfigsImpl -> BackupResStorCfgsImpl
RecoveryServicesBackupCrrManagementClientImpl -> RsbCrrMgmtClientImpl
BackupUsageSummariesCRRsClientImpl -> BackupUsageSummCRRsClientImpl
BackupProtectedItemsCrrsClientImpl -> BackupProtItemsCrrsClientImpl
BackupResourceConfigResourceImpl -> BackupResConfigResImpl
BackupResourceStorageConfigsClientImpl -> BackupResStorCfgsClientImpl
AadPropertiesOperationsClientImpl -> AadPropsOpsClientImpl
RecoveryPointResourceList -> RecoveryPtResList
RecoveryServicesBackupCrrManagementClient -> RsbCrrMgmtClient
BackupResourceConfigResourceInner -> BackupResConfigResInner
AzureWorkloadPointInTimeRestoreRequest -> AzureWorkloadPitRestoreReq
MabFileFolderProtectedItemExtendedInfo -> MabFileFolderProtItemExtInfo
AzureWorkloadSQLRecoveryPointExtendedInfo -> AzureWorkloadSQLRecoveryPtExtInfo
AzureWorkloadSQLPointInTimeRestoreRequest -> AzureWorkloadSQLPitRestoreReq
AzureVmWorkloadSAPAseDatabaseProtectedItem -> AzureVmWorkloadSAPAseDbProtItem
AzureWorkloadSAPHanaPointInTimeRestoreRequest -> AzureWorkloadSAPHanaPitRestoreReq
AzureIaaSClassicComputeVMProtectedItem -> AzureIaaSClassicComputeVMProtItem
AzureWorkloadSQLPointInTimeRecoveryPoint -> AzureWorkloadSQLPitRecoveryPt
AzureVmWorkloadSQLDatabaseProtectedItem -> AzureVmWorkloadSQLDbProtItem
AzureVmWorkloadProtectedItemExtendedInfo -> AzureVmWorkloadProtItemExtInfo
OperationStatusRecoveryPointExtendedInfo -> OpStatusRecoveryPtExtInfo
AzureVmWorkloadSAPHanaDatabaseProtectedItem -> AzureVmWorkloadSAPHanaDbProtItem
AzureFileshareProtectedItemExtendedInfo -> AzureFileshareProtItemExtInfo
AzureWorkloadSAPHanaPointInTimeRecoveryPoint -> AzureWorkloadSAPHanaPitRecoveryPt
OperationStatusProvisionILRExtendedInfo -> OpStatusProvisionILRExtInfo
| generate-sample: true | ||
| flavor: "azure" | ||
| "@azure-tools/typespec-java": | ||
| emitter-output-dir: "{output-dir}/{service-dir}/azure-resourcemanager-recoveryservicesbackupcrr" |
Member
There was a problem hiding this comment.
the value should be {output-dir}/{service-dir}/azure-resourcemanager-recoveryservicesbackupcrossregionrestore
| "@azure-tools/typespec-java": | ||
| emitter-output-dir: "{output-dir}/{service-dir}/azure-resourcemanager-recoveryservicesbackupcrr" | ||
| namespace: "com.azure.resourcemanager.recoveryservicesbackupcrr" | ||
| service-name: "Recovery Services Backup Crr" |
Member
There was a problem hiding this comment.
The value should be Recovery Services Backup Cross-Region-Restore
| flavor: azure | ||
| experimental-extensible-enums: true | ||
| package-details: | ||
| name: "@azure/arm-recoveryservicesbackupcrr" |
Member
There was a problem hiding this comment.
Consider using the namespace @azure/arm-recoveryservicesbackupcrossregionrestore
| use-object-for-unknown: true | ||
| "@azure-tools/typespec-ts": | ||
| compatibility-lro: true | ||
| emitter-output-dir: "{output-dir}/{service-dir}/arm-recoveryservicesbackupcrr" |
Member
There was a problem hiding this comment.
The value should be {output-dir}/{service-dir}/arm-recoveryservicesbackupcrossregionrestore
| name: "@azure/arm-recoveryservicesbackupcrr" | ||
| "@azure-tools/typespec-go": | ||
| service-dir: "sdk/resourcemanager/recoveryservices" | ||
| emitter-output-dir: "{output-dir}/{service-dir}/armrecoveryservicesbackupcrr" |
Member
There was a problem hiding this comment.
The value should be {output-dir}/{service-dir}/armrecoveryservicesbackupcrossregionrestore
| "@azure-tools/typespec-go": | ||
| service-dir: "sdk/resourcemanager/recoveryservices" | ||
| emitter-output-dir: "{output-dir}/{service-dir}/armrecoveryservicesbackupcrr" | ||
| module: "github.com/Azure/azure-sdk-for-go/{service-dir}/armrecoveryservicesbackupcrr" |
Member
There was a problem hiding this comment.
The value should be github.com/Azure/azure-sdk-for-go/{service-dir}/armrecoveryservicesbackupcrossregionrestore
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Migrates the Azure Backup Cross-Region-Restore (CRR / passive-stamp) API surface from the legacy hand-authored Swagger (
stable/2023-01-15/bms.json) into a new dedicated top-level TypeSpec project atspecification/recoveryservicesbackupcrr/, publishing a new stable API version 2026-07-15.Commits
tsp-client convert(raw converter output).2026-07-15, service title, description, common-types v6), tspconfig.yaml (ARM emitters + distinct...crrSDK package names), examples moved2023-01-15->2026-07-15and retagged.Not yet included (tracked, coming next)
stable/2026-07-15/bms.jsonoutput (intentionally held back)Resource-base migration, x-ms-pageable / x-ms-odata, getAccessToken 400, raw-@routeCRR ops, Tracked->Proxy, enum-doc cleanupWorkloadCrrAccessTokenNotes
Microsoft.RecoveryServices(unchanged); this is a repo/CODEOWNERS reorganization into a dedicated top-level folder.missing-operations-endpointwill be suppressed.