resolveArmResources still sees full version view when passed TCGC mutated realm program
- Dominant language
- TypeScript
- Stars
- 27
- Forks
- 90
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 156
Description
## Summary
`resolveArmResources(program)` does not appear to respect the TCGC version-mutated realm/program when used from the Azure SDK for .NET management emitter. This means it can still return ARM resources that were removed from the selected/current SDK version.
This is related to the broader version/projection mismatch tracked in #4800, but this issue captures the concrete experiment with TCGC's mutated realm API.
## Context
The .NET management emitter currently compares two ARM resource discovery paths:
1. Legacy SDK-model-based detection, which goes through TCGC/C# SDK model construction and therefore follows the selected SDK version/projection.
2. `resolveArmResources(program)`, which reads ARM resource information from the TypeSpec ARM library state on the `Program`.
In several real RPs, `resolveArmResources` returns resources that are real ARM resources in another API version, but are not part of the selected/current SDK version. Examples observed during Azure SDK validation include NetApp, Monitor.Workspaces, and ResilienceManagement.
## Experiment
We tried forcing TCGC to build its mutated realm and passing that realm's program to `resolveArmResources`:
```ts
sdkContext.getMutatedGlobalNamespace();
const provider = resolveArmResourcesFromLibrary(
sdkContext.__mutatedRealm?.program ?? program
);
```
Experiment commit in the .NET SDK repo:
https://github.com/ArcturusZhang/azure-sdk-for-net/commit/a1b326d8677
The commit also keeps a skipped repro test named:
```ts
it.skip("resolveArmResources uses the version-mutated program", async () => { ... })
```
The repro defines a resource decorated with `@removed(Versions.\`2024-05-01\`)`. The legacy SDK-model path returns only the current-version resource, but `resolveArmResources` still returns the removed resource as well.
## Result
Passing `sdkContext.__mutatedRealm?.program` does not fix the issue. The removed-version resource is still returned.
From the experiment, it looks like `__mutatedRealm.program` is still the original `Program` object. The mutation is tracked as realm state associated with the program/types, not as a separate filtered/mutated `Program` instance that `resolveArmResources(program)` can observe by only receiving a `Program`.
## Expected behavior
There should be a supported way for `resolveArmResources` to run against the same version-mutated view that TCGC/C# uses, so resource detection only returns resources visible in the selected SDK version/projection.
Possible directions:
- Let `resolveArmResources` accept a mutated namespace/realm or projection-aware context instead of only `Program`.
- Add an option/API for resolving ARM resources from the TCGC-mutated view.
- Expose enough version/projection filtering metadata from `resolveArmResources` so emitters can reliably post-filter resources and operations.
## Why this matters
Without version-aware resource resolution, SDK emitters can incorrectly treat resources from other API versions as part of the current package. This creates false positives in generated ARM provider resource metadata and makes it difficult to replace the current SDK-model-based detector with `resolveArmResources`.
Contributor guide
Assessment
This issue has not been assessed yet.