AsyncGraphTransport silently skips the entire middleware pipeline (URL-replace, retry, redirect) with microsoft-kiota-http>=1.13.0
还没有人认领这个 Issue。
评估
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- Python
- 星标
- 288
- 派生
- 52
- 平均合并
- 8 小时 10 分钟
- 30 天内合并 PR
- 1
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoftgraph/msgraph-sdk-python-core 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 88/100
-
status:waiting-for-triage type:bug
难度 2/5 1-3 小时 新手友好度 75/100
-
status:waiting-for-triage type:bug
难度 2/5 1-3 小时 新手友好度 68/100
microsoftgraph/msgraph-sdk-python-core#1030 · 2 条评论 · 4 个 reaction ·
-
status:waiting-for-triage type:feature
难度 3/5 1-2 天 新手友好度 52/100
-
status:waiting-for-triage type:bug
难度 3/5 1-2 天 新手友好度 48/100
查看 microsoftgraph/msgraph-sdk-python-core 的全部 Issue
相似的 Issue
-
bug confirmed issue
难度 2/5 1-3 小时 新手友好度 75/100
open-webui/open-webui#30750 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
enhancement
难度 2/5 1-3 小时 新手友好度 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
-
good first issue
难度 1/5 1 小时以内 新手友好度 90/100