Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[v3 wrappers] Make session request-adapter caching Graph-profile-aware

Ouverte
  • Quelque chose ne va pas ?
#3,873 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
csharp, powershell
Domaine
authentication, backend-api-design, testing

Piste de recherche

Start with SessionAdapterCache.cs and GraphClientCmdlet.cs to trace how the session HttpClient selects and reuses adapters, then inspect CmdletEmitter.cs for the profile passed by generated wrappers. Review SessionAdapterCacheTests.cs and add stub-transport URI regressions for both profile invocation orders, including reuse and client replacement; done means requests retain the intended profile without stale session transport.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

status:waiting-for-triage type:bug
Describe the bug

Track the shared runtime/generator routing problem discussed in #3839 for a separate follow-up PR, rather than extending the Bookings retirement change.

When wrapper cmdlets use the active Connect-MgGraph session without -AccessToken, GraphClientCmdlet.GetRequestAdapter() returns an adapter from SessionAdapterCache. The cache is keyed only by reference identity of the session HttpClient, so v1.0 and beta wrappers share one adapter. Generated Kiota clients set RequestAdapter.BaseUrl to their profile URL only when it is empty, then capture that value in their path parameters.

Consequently, the first profile used in a session wins: running a v1.0 wrapper first can make subsequent beta Bookings cmdlets call /v1.0/...; running beta first can make subsequent v1.0 wrappers call /beta/.... The correct /solutions/bookingBusinesses path does not prevent this API-version misrouting.

Expected behavior

Each wrapper uses its intended Graph profile regardless of invocation order or concurrent activity. Adapters may be reused for the same session transport and profile, but must not share mutable profile-specific BaseUrl state across v1.0 and beta.

Retain the existing session transport and lifecycle behavior: reconnecting, changing request context, or disconnecting must not leave requests bound to a stale session HttpClient.

How to reproduce

Code-derived reproduction scenario from review; no live Graph request reproduction was performed while filing this issue:

  1. Establish a Connect-MgGraph session and use wrapper cmdlets without -AccessToken.
  2. Invoke a v1.0 wrapper command, for example from Calendar, so its client initializes the cached adapter's base URL to https://graph.microsoft.com/v1.0.
  3. Invoke a beta Bookings wrapper command in the same session. Its generated client sees a nonempty adapter base URL and retains /v1.0 instead of selecting /beta.
  4. Repeat with beta first, then v1.0, to observe the reverse routing risk.

Add deterministic tests that capture outgoing request URIs with a stub transport, without depending on live Graph data.

SDK Version

Unreleased powershell-v3 wrapper implementation, observed during #3839 at commit 037ab5db249e97a44338a0b08a2ecb0dc67e0e23. No claim is made about released v2 service modules.

Latest version known to work for scenario above?

Unknown.

Known Workarounds

Supplying -AccessToken currently creates a separate request adapter per invocation and bypasses this session adapter cache. This is a different authentication path, not a fix for session-based usage.

Do not fix this by unconditionally overwriting the shared adapter's BaseUrl: that still mutates shared state and can misroute concurrent or subsequent requests. Removing caching outright also loses its session-lifecycle purpose.

Debug output

N/A. Report based on the referenced review discussion and current runtime/generator source inspection; no live request logs were collected.

Configuration

Applies to v1.0 and beta wrapper modules sharing the same session HttpClient. No OS-specific dependency identified; runtime reproduction across PowerShell editions has not been performed.

Other information

Relevant sources:

  • src/GraphWrapperRuntime/Runtime/SessionAdapterCache.cs: single cached adapter keyed only by session client identity.
  • src/GraphWrapperRuntime/Runtime/GraphClientCmdlet.cs: adapter acquisition does not receive a Graph profile.
  • tools/WrapperGenerator/CmdletEmitter.cs: emits parameterless GetRequestAdapter() calls.
  • src/Bookings/wrapper/beta/Client/ApiClient.cs: profile base URL is assigned only when the adapter base URL is empty.
  • src/GraphWrapperRuntime/Runtime.Tests/SessionAdapterCacheTests.cs: existing session-client reuse/replacement coverage.

Suggested follow-up scope and acceptance criteria:

  • Make adapter acquisition and cache identity profile-aware, for example (session HttpClient reference, Graph profile), while preserving the authenticated session transport.
  • Update the generator to supply the intended profile and regenerate affected wrapper sources through the established workflow; avoid hand-editing generated clients.
  • Add same-session v1.0 → beta → v1.0 and beta → v1.0 → beta request-URI regressions.
  • Cover same-profile reuse, distinct adapters for different profiles, client replacement/context changes, and interleaved or concurrent requests without cross-profile mutation.
  • Keep -AccessToken behavior and the supported Bookings /solutions/... cmdlet surface unchanged.

Original finding: https://github.com/microsoftgraph/msgraph-sdk-powershell/pull/3839#discussion_r4405262434

Follow-up explanation requested for tracking: https://github.com/microsoftgraph/msgraph-sdk-powershell/pull/3839#discussion_r4405694648

Langage dominant
C#
Étoiles
904
Forks
235
Merge moyen
2 j 4 h
PR mergées (30 j)
19

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoftgraph/msgraph-sdk-powershell

Toutes les issues de microsoftgraph/msgraph-sdk-powershell

Issues similaires

Plus d'issues C#

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.