AsyncGraphTransport silently skips the entire middleware pipeline (URL-replace, retry, redirect) with microsoft-kiota-http>=1.13.0
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 76/100
Línea de trabajo
Start in msgraph_core/middleware/async_graph_transport.py at handle_async_request and inspect the microsoft-kiota-http 1.13.0 request-options contract. Reproduce with the issue's package versions and verify that UrlReplaceHandler runs for a client.me request. Done means the middleware pipeline runs with the newer dependency and the .me URL is rewritten instead of producing the reported 404.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
AsyncGraphTransport.handle_async_request gates its entire middleware pipeline (URL-replace, redirect, retry, telemetry, ...) on hasattr(request, 'options'). microsoft-kiota-http >= 1.13.0 stopped attaching a bare .options attribute to httpx.Request and moved per-request options to request.extensions["kiota_request_options"] instead (every handler's _get_current_options in that package switched from getattr(request, "options", None) to request.extensions.get(REQUEST_OPTIONS_KEY)).
msgraph-core was never updated to match, so with microsoft-kiota-http>=1.13.0, hasattr(request, 'options') is always False, and the transport silently falls through to sending the raw request with no middleware at all, including UrlReplaceHandler, which is what normally rewrites the SDK's .me placeholder path (/users/me-token-to-replace) to /me.
The practical symptom: any call built via client.me... (e.g. client.me.get(), client.me.mail_folders...) 404s with:
The requested user 'me-token-to-replace' is invalid. (status 404)
Repro
pip install msgraph-core==1.5.1 microsoft-kiota-http==1.13.0 msgraph-sdk==1.63.0
import asyncio
from msgraph import GraphServiceClient
# ... build client per the standard sample with default credential
async def main():
me = await client.me.get()
print(me)
asyncio.run(main())
# -> ODataError: The requested user 'me-token-to-replace' is invalid. (status 404)
Instrumenting UrlReplaceHandler.send confirms it is never invoked with this version pair; it is invoked (and the URL rewritten correctly) when downgrading to microsoft-kiota-http==1.12.3, with everything else held constant.
Root cause pointer
msgraph_core/middleware/async_graph_transport.py:
async def handle_async_request(self, request: httpx.Request) -> httpx.Response:
if self.pipeline and hasattr(request, 'options'):
...
response = await self.pipeline.send(request)
return response
response = await self.transport.handle_async_request(request) # no middleware runs
return response
This hasattr check is the only gate deciding whether the middleware pipeline runs at all. It needs to check request.extensions.get("kiota_request_options") (or whatever the current microsoft-kiota-http contract is) in addition to / instead of the legacy .options attribute, for compatibility with microsoft-kiota-http>=1.13.0.
Why this is worth fixing here (vs. just in kiota-http)
msgraph-core's own package metadata declares Requires-Dist: microsoft-kiota-http<2.0.0,>=1.11.6, i.e. it claims to support the full 1.11.6-1.x range, but silently breaks (with no exception, just a 404 from Graph) for every version >= 1.13.0. This is a compatibility contract violation that pip/uv resolvers have no way to detect, since the declared range is technically satisfiable and nothing raises, it just quietly stops rewriting URLs (and skips retry/redirect/telemetry too).
Environment
msgraph-core==1.5.1(latest on PyPI as of this report)microsoft-kiota-http==1.13.0(broken) vs==1.12.3(working)msgraph-sdk==1.63.0- Python 3.13
Found while debugging a downstream consumer (the-hcma/blumkin#354), where the global install (uv tool install -e ., which re-resolves fresh from PyPI) picked up the broken pair while the project's own lockfile-pinned dev environment (microsoft-kiota-http==1.12.3) did not.
- Lenguaje dominante
- Python
- Estrellas
- 288
- Forks
- 52
- Merge medio
- 8 h 10 min
- PR fusionados (30 d)
- 1
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoftgraph/msgraph-sdk-python-core
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
Logging to root logger Abiertostatus:waiting-for-triage type:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Missing 'deprecated' dependency Abiertostatus:waiting-for-triage type:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
microsoftgraph/msgraph-sdk-python-core#1030 · 2 comentarios · 4 reacciones ·
-
Replace httpx with httpx2 Abiertostatus:waiting-for-triage type:feature
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
-
status:waiting-for-triage type:bug
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
Todos los issues de microsoftgraph/msgraph-sdk-python-core
Issues similares
-
essnmx good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
-
[Feature] 奇物选择添加优先级 Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
syfoud/Simulated_Scepter#174 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Giskard-AI/giskard-oss#2840 · 1 comentario ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Abiertoarea: repo bug perceived difficulty: 2
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
yeti-platform/yeti#1380 ·