Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#3,873 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp, powershell
Área
authentication, backend-api-design, testing

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
C#
Estrellas
904
Forks
235
Merge medio
1 d 21 h
PR fusionados (30 d)
18

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoftgraph/msgraph-sdk-powershell

Todos los issues de microsoftgraph/msgraph-sdk-powershell

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.