Publish command: GraphApiService acquires a new token for every Graph API call (no caching in Azure CLI path)

[pratapladhani]

Summary

During a365 publish, the MOS prerequisites check acquires a new Graph API token for every single API call by spawning 2 az CLI subprocesses each time. A single publish command spawns ~22 subprocesses just for token acquisition.

Evidence

Captured from a365 publish --verbose output:

• 11 separate token acquisitions during MOS prerequisites check alone
• Each acquisition spawns 2 az CLI processes = 22 subprocess spawns
• The token is valid for ~60 minutes but is never cached/reused

Breakdown of calls in CheckMosPrerequisitesAsync:

Operation	Graph API calls	Token acquisitions
1 SP lookup (first-party)	1	1
3 SP lookups (resource apps)	3	3
3 admin consent checks (SP lookup + grant query each)	6	6
MOS token acquisition	1	1
Total	11	11 x 2 = 22 az processes

Redundant lookups

Admin consent verification re-looks up service principals that were already verified in the service principal check phase.

Root Cause

GraphApiService.EnsureGraphHeadersAsync() is called before every GraphGetAsync/GraphPostAsync call, and in the Azure CLI path it always calls GetGraphAccessTokenAsync() which spawns fresh az subprocesses. There is no token caching for the Azure CLI code path (though the IMicrosoftGraphTokenProvider path does cache).

Proposed Fix

1. Cache the Azure CLI token in GraphApiService with a reasonable TTL (e.g., 5 minutes or until expiry)
2. Pass cached service principal IDs from the first check phase into the admin consent check phase to avoid redundant lookups
3. Consider batching Graph API calls where possible

Impact

• Publish command takes significantly longer than necessary due to subprocess overhead
• Each az process spawn adds ~2-3 seconds, so ~22 spawns = ~45-60 seconds of token acquisition overhead
• User experience: verbose output is cluttered with repetitive 'Acquiring Graph token' debug messages

Related

• Issue PublishCommand: All error paths return exit code 0 instead of non-zero #264 (PublishCommand exit codes)

[github-actions]

[AUTO-TRIAGE] Team Assistant Triage

This issue has been automatically analyzed and triaged.

AI Decision Reasoning: Type: Classified as 'bug' because the issue describes inefficient and redundant behavior in token acquisition during the publish command, which negatively impacts performance and user experience.
Priority: Assigned P2 because the issue significantly affects the publish command's execution time and user experience but does not prevent the command from functioning entirely.
Copilot: This issue involves caching logic, architectural changes, and optimization of subprocess calls, which require a deeper understanding of the application's business logic and performance considerations. These tasks are beyond Copilot's capability to handle autonomously.
Assignment: Josh Oratz is a backend engineer with expertise in CLI, dotnet, csharp, and Azure, which aligns well with the issue's focus on optimizing the Azure CLI token acquisition process in a backend service. Additionally, his contribution count (18) is moderate compared to others, ensuring a balanced workload.
Labels: Applied labels bug, P2 based on issue type and priority

Labels and assignee have been applied based on this analysis.

[github-actions]

[AUTO-TRIAGE] Results

Classification: bug
Priority: P2
Confidence: 95.0%

Recommended Assignee: @joratz

Analysis:
type rationale: Classified as 'bug' because the issue describes inefficient and redundant behavior in token acquisition during the publish command, which negatively impacts performance and user experience.

priority rationale: Assigned P2 because the issue significantly affects the publish command's execution time and user experience but does not prevent the command from functioning entirely.

copilot rationale: This issue involves caching logic, architectural changes, and optimization of subprocess calls, which require a deeper understanding of the application's business logic and performance considerations. These tasks are beyond Copilot's capability to handle autonomously.

assignment rationale: Josh Oratz is a backend engineer with expertise in CLI, dotnet, csharp, and Azure, which aligns well with the issue's focus on optimizing the Azure CLI token acquisition process in a backend service. Additionally, his contribution count (18) is moderate compared to others, ensuring a balanced workload.

labels rationale: Applied labels bug, P2 based on issue type and priority

[SUGGESTION] Suggested Approach

1. Implement token caching in GraphApiService.GetGraphAccessTokenAsync() by storing the token in memory with a TTL (e.g., 5 minutes or until expiry). Use a ConcurrentDictionary or similar structure to cache tokens per user/session. Update the src/Services/GraphApiService.cs file to include this logic.
2. Refactor CheckMosPrerequisitesAsync in src/Services/PublishService.cs to pass cached service principal IDs from the service principal lookup phase into the admin consent check phase. This avoids redundant lookups and reduces the number of Graph API calls.
3. Batch Graph API calls where possible by combining multiple requests into a single call using batch endpoints provided by Microsoft Graph API. Update GraphGetAsync and GraphPostAsync in GraphApiService.cs to support batching and adjust dependent methods accordingly.
4. Add integration tests in src/Tests/Microsoft.Agents.A365.DevTools.Cli.Tests/Services to verify that token caching works correctly and reduces the number of az subprocess spawns during a365 publish. Simulate scenarios with multiple Graph API calls to confirm caching behavior.
5. Update the verbose logging in GraphApiService.EnsureGraphHeadersAsync() to include information about token caching (e.g., whether a cached token was used or a new token was acquired). This will help users and developers diagnose caching behavior during a365 publish.

---

Generated by TeamAssistant Auto-Triage powered by GitHub Models