Fix issues when we have singleton resource with a customized name by ArcturusZhang · Pull Request #3594 · Azure/typespec-azure

ArcturusZhang · 2025-12-01T08:02:21Z

Previously the segment default was hard-coded in a function checking if a segment in path is a variable.
This PR modifies it to accept an optional extra singletonResourceName parameter - if match, we will return true as variable segment.

This PR also updates the ResolvedResource API to add a new property singletonResourceNames

pkg-pr-new · 2025-12-01T08:04:23Z

Open in StackBlitz

npm i https://pkg.pr.new/Azure/typespec-azure/@azure-tools/typespec-azure-resource-manager@3594

commit: 956cd97

azure-sdk · 2025-12-01T08:07:15Z

All changed packages have been documented.

✅ @azure-tools/typespec-azure-resource-manager

Show changes

`@azure-tools/typespec-azure-resource-manager` - fix ✏️

Fix issues in resolveArmResources when we have singleton resource with a customized name

azure-sdk · 2025-12-01T08:17:53Z

You can try these changes here

🛝 Playground	🌐 Website

markcowl · 2025-12-03T01:17:18Z

packages/typespec-azure-resource-manager/src/resource.ts

-      instanceSegments.push(segments[i]);
-      instanceSegments.push(segments[i + 1]);
-    } else if (i + 1 === segments.length) {
+    if (i + 1 === segments.length) {


I don't think this is safe. We should look for the model being marked as a singleton.

I made some updates around this part, please take a look again.

ArcturusZhang · 2025-12-05T06:47:56Z

packages/typespec-azure-resource-manager/src/resource.ts

+    if (i + 1 === segments.length - 1 && isVariableSegment(segments[i + 1], singletonResourceName)) {
+      typeSegments.push(segments[i]);
+      instanceSegments.push(segments[i]);
+      instanceSegments.push(segments[i + 1]);


so we only consider the singletonResourceName when the current segment is the last segement.

ArcturusZhang · 2025-12-05T06:50:29Z

packages/typespec-azure-resource-manager/test/resource-resolution.test.ts

        path: "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{providerName}/{resourceType}/{resourceName}/{childResourceType}/{childResourceName}/providers/Microsoft.Bar/bars/{barName}/basses/default/actionName/doSomething/doSomethingElse/andAnotherThing",
        kind: "read",
+        singletonResourceName: "default",
        expected: {
          resourceType: {
            provider: "Microsoft.Bar",
-            types: ["bars", "basses"],
+            types: ["bars"],
          },
          resourceInstancePath:
-            "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{providerName}/{resourceType}/{resourceName}/{childResourceType}/{childResourceName}/providers/Microsoft.Bar/bars/{barName}/basses/default",
+            "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{providerName}/{resourceType}/{resourceName}/{childResourceType}/{childResourceName}/providers/Microsoft.Bar/bars/{barName}",


the result changed because of the change above.
In this path, we have a default but it is not at the end.

Also I have concerns: why would we try to rebuild the resourceInstancePath from the path any way? Should we just use the READ request path as the resource instance path? I think ARM did this in their logic, and resource type is then built out of this path.

do you think if this makes sense that I changed the result? Or we should just remove this?

I created this issue to track this: #3620

I think the previous behavior is more accurate. We need to use the resourceInstancePath (or resource type) for matching, because legacy APIs and low-level APIs can be used to describe resource operations, and, if they are, we want them to be returned in this call.

markcowl

First, we need to target this PR at release/december-2025,

scond I have a couple of minor comments, and a slight algorithmic change:

We should check for 'default' as well as the resourceInstance Name from the resource type
We should check against the resourceInstanceName (and default) whwnever we are looking to see that an enven-numbered segment is a variable segment

I think this will give us better results in legacy scenarios

markcowl · 2025-12-11T23:52:39Z

packages/typespec-azure-resource-manager/src/resource.ts


-function isVariableSegment(segment: string): boolean {
-  return (segment.startsWith("{") && segment.endsWith("}")) || segment === "default";
+function isVariableSegment(segment: string, singletonResourceName?: string): boolean {


I think we want to do a lowercase transform over both the segment and the name

Also, I think we could do this over an array of singleton resource names, but this isn't required for this PR, we cna add it when we add singleton recognition for union and enum resource name types

I think we should also continue to use 'default' as a singleton resource name, in addition to the singleton resource name from getSingletonKey

markcowl · 2025-12-12T00:02:04Z

packages/typespec-azure-resource-manager/src/resource.ts


-    if (i + 1 < segments.length && isVariableSegment(segments[i + 1])) {
+    // if the next segment is the last segment
+    if (


I think if we change this logic, we will fix the issues below - it makes sense that the singleton resource name should just always be checked when looking for a variable segment.

I think there is still a case to think about, when multiple resources in the resource type are singletons

markcowl · 2025-12-12T00:04:27Z

packages/typespec-azure-resource-manager/test/resource-resolution.test.ts

+    expect(employee).toMatchObject({
+      kind: "Tracked",
+      providerNamespace: "Microsoft.ContosoProviderHub",
+      type: expect.anything(),


we should check the resourceInstance path and the singleton names here as well

markcowl · 2025-12-12T00:05:39Z

packages/typespec-azure-resource-manager/test/resource-resolution.test.ts

+    expect(employee).toMatchObject({
+      kind: "Tracked",
+      providerNamespace: "Microsoft.ContosoProviderHub",
+      type: expect.anything(),


we should check singleton resource names and resourceInstancePath

markcowl · 2025-12-12T00:06:38Z

packages/typespec-azure-resource-manager/test/resource-resolution.test.ts

+      providerNamespace: "Microsoft.ContosoProviderHub",
+      type: expect.anything(),
+      resourceType: {
+        provider: "Microsoft.ContosoProviderHub",


we should add in resourceInstancePath and singletonNames checks

markcowl

I may be missing this but I don't see the changes to address my comments on singleton resources. I think only minimal changes are needed here, once this is brought up to date with the main branch, and we should be able to merge this next week.

markcowl · 2025-12-23T22:48:07Z

packages/typespec-azure-resource-manager/test/resource-resolution.test.ts

        path: "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{providerName}/{resourceType}/{resourceName}/{childResourceType}/{childResourceName}/providers/Microsoft.Bar/bars/{barName}/basses/default/actionName/doSomething/doSomethingElse/andAnotherThing",
        kind: "read",
+        singletonResourceName: "default",
        expected: {
          resourceType: {
            provider: "Microsoft.Bar",
-            types: ["bars", "basses"],
+            types: ["bars"],
          },
          resourceInstancePath:
-            "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{providerName}/{resourceType}/{resourceName}/{childResourceType}/{childResourceName}/providers/Microsoft.Bar/bars/{barName}/basses/default",
+            "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{providerName}/{resourceType}/{resourceName}/{childResourceType}/{childResourceName}/providers/Microsoft.Bar/bars/{barName}",


I think the previous behavior is more accurate. We need to use the resourceInstancePath (or resource type) for matching, because legacy APIs and low-level APIs can be used to describe resource operations, and, if they are, we want them to be returned in this call.

microsoft-github-policy-service · 2026-02-09T16:27:41Z

Hi @@ArcturusZhang. Your PR has had no update for 30 days and it is marked as a stale PR. If it is not updated within 30 days, the PR will automatically be closed. If you want to refresh the PR, please remove the stale label.

microsoft-github-policy-service bot added the lib:azure-resource-manager Issues for @azure-tools/typespec-azure-core library label Dec 1, 2025

markcowl reviewed Dec 3, 2025

View reviewed changes

ArcturusZhang commented Dec 5, 2025

View reviewed changes

ArcturusZhang marked this pull request as ready for review December 5, 2025 07:21

ArcturusZhang requested review from bterlson and timotheeguerin as code owners December 5, 2025 07:21

markcowl changed the base branch from main to release/december-2025 December 11, 2025 18:02

markcowl changed the base branch from release/december-2025 to main December 11, 2025 18:03

markcowl reviewed Dec 12, 2025

View reviewed changes

ArcturusZhang added 7 commits December 12, 2025 16:22

add a test case

6940e1a

fix the issue

c4d1267

add tests for one singleton resource

b9a7446

patch up some tests

451d7b9

update

290dd82

update changelog

f5f5910

run prettier

155ce30

ArcturusZhang force-pushed the introduce-tests-for-bug branch from 956cd97 to 155ce30 Compare December 12, 2025 08:23

markcowl reviewed Dec 23, 2025

View reviewed changes

microsoft-github-policy-service bot added the stale Mark a PR that hasn't been recently updated and will be closed. label Feb 9, 2026

Comments

Conversation

ArcturusZhang commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pkg-pr-new bot commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

azure-sdk commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

@azure-tools/typespec-azure-resource-manager - fix ✏️

Uh oh!

azure-sdk commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

markcowl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

markcowl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

microsoft-github-policy-service bot commented Feb 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ArcturusZhang commented Dec 1, 2025 •

edited

Loading

pkg-pr-new bot commented Dec 1, 2025 •

edited

Loading

azure-sdk commented Dec 1, 2025 •

edited

Loading

`@azure-tools/typespec-azure-resource-manager` - fix ✏️

azure-sdk commented Dec 1, 2025 •

edited

Loading