[NEW] 🟡 Warning [Self-consistency / Breaking-changes §"Resource naming rules"]

Description and NamePattern disagree on the maximum diskName length:

• The @@doc on line 134 of this file says: "The maximum name length is 80 characters."
• The NamePattern above (^[^_\W][\w-._]{0,89}(?<![-.])$) allows 1 + 89 = 90 characters.

This contradiction propagates verbatim into:

• specification/compute/resource-manager/Microsoft.Compute/Compute/stable/2024-03-02/DiskRP.json — lines 1255, 1300, 1448, 1551, 1616, 1694
• specification/compute/resource-manager/Microsoft.Compute/Compute/stable/2025-01-02/DiskRP.json — lines 1255, 1300, 1454, 1557, 1622, 1703

Since the explicit goal of this PR is to align the spec with DiskRP service-side validation, the value chosen here has to be exactly right — an over-strict pattern breaks legitimate names, an under-strict one mis-documents the service. Note that the four other resources in this PR use {0,79} (1–80 chars) matching their "80 characters" descriptions, so the 89 looks like an off-by-one typo.

Classification: NEW. The previous stable revisions of these path parameters had no pattern at all, so this is not pre-existing technical debt — it is introduced by this PR.

Suggested fix (if the 80-character description is correct):

-    NamePattern = "^[^_\\W][\\w-._]{0,89}(?<![-.])$"
+    NamePattern = "^[^_\\W][\\w-._]{0,79}(?<![-.])$"

If the service truly accepts 90 characters, please update the @@doc on line 134 (and the matching description text in both DiskRP.json files) to read "The maximum name length is 90 characters." Either way, please confirm with the DiskRP service team before merging.

Thanks, good catch. I had initially used the 90-character pattern because DiskRP has special VMSS disk handling and privileged snapshot validation paths that can allow longer names, and I wanted to avoid blocking any valid service scenarios.

For public Swagger metadata though, I agree NamePattern should match the documented public contract. I updated diskName to {0,79} so it aligns with the 80-character description, regenerated both DiskRP.json files, and applied the same correction to snapshotName.

I left diskRestorePointName and privateEndpointConnectionName out of scope because they are nested/child resource names, not the public top-level DiskRP resource names covered here. Their public validation contracts should be confirmed separately before adding NamePattern.

[NEW] 🟡 Warning [Self-consistency / Breaking-changes §"Resource naming rules"]

Description and NamePattern disagree on the maximum snapshotName length:

• The @@doc on line 128 of this file says: "The max name length is 80 characters."
• The NamePattern above (^[^_\W][\w-._]{0,89}(?<![-.])$) allows 1 + 89 = 90 characters.

This contradiction propagates verbatim into:

• specification/compute/resource-manager/Microsoft.Compute/Compute/stable/2024-03-02/DiskRP.json — lines 2083, 2131, 2222, 2301, 2366, 2441
• specification/compute/resource-manager/Microsoft.Compute/Compute/stable/2025-01-02/DiskRP.json — same six operations (analogous lines)

Same issue as Disk.tsp (diskName). The other resources in this PR (diskAccessName, diskEncryptionSetName) use {0,79} (1–80 chars) matching their "80 characters" descriptions, so the 89 here looks like a typo.

Classification: NEW. The previous stable revisions of these path parameters had no pattern at all, so this is not pre-existing technical debt — it is introduced by this PR.

Suggested fix (if the 80-character description is correct):

-    NamePattern = "^[^_\\W][\\w-._]{0,89}(?<![-.])$"
+    NamePattern = "^[^_\\W][\\w-._]{0,79}(?<![-.])$"

If the service truly accepts 90 characters, please update the @@doc on line 128 (and the matching description text in both DiskRP.json files) to read "The max name length is 90 characters." Either way, please confirm with the DiskRP service team before merging.

Thanks, good catch. I had initially used the 90-character pattern because DiskRP has special VMSS disk handling and privileged snapshot validation paths that can allow longer names, and I wanted to avoid blocking any valid service scenarios.

For public Swagger metadata though, I agree NamePattern should match the documented public contract. I updated diskName to {0,79} so it aligns with the 80-character description, regenerated both DiskRP.json files, and applied the same correction to snapshotName.

I left diskRestorePointName and privateEndpointConnectionName out of scope because they are nested/child resource names, not the public top-level DiskRP resource names covered here. Their public validation contracts should be confirmed separately before adding NamePattern.