Propagate FunctionInvocationId for single-instance and bulk purge requests

未关闭
  • 哪里不对？
#630 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

@Fire162 已经在做这个了。

开始于 2026年11月3日。

  • #631 来自 @Fire162 —— 未关闭

评估

难度
3/5
预计耗时
1-2 天
新手友好度
72/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
python
领域
api

调研方向

Start in azure/durable_functions/models/DurableOrchestrationClient.py at purge_instance_history and purge_instance_history_by, then read azure/durable_functions/models/utils/http_utils.py to understand the existing DELETE helper and header contract. Add regression coverage for both purge calls, including clients with distinct invocation IDs and without one; done means the outgoing header is correct and other purge behavior remains unchanged.

由索引模型根据 Issue 内容生成。

描述

Needs: Triage :mag:

Summary

Python Durable client purge operations do not forward the originating Azure Functions invocation ID, so the host cannot emit the correlated ClientOperationReceived logs needed by the remaining Python purge E2E assertions in Azure/azure-functions-durable-extension#3327.

This is a source-inspection report, not a deployed-application incident. The scope is the existing single-instance and bulk purge APIs, not adding new orchestration capabilities.

SDK line and next-generation tracking

This issue covers the stable Python v1 HTTP implementation in this repository; the current stable PyPI release is azure-functions-durable 1.7.0. The newer Python v2 Functions SDK is maintained in microsoft/durabletask-python under azure-functions-durable and has a published 2.0.0rc3 preview. Its separate gRPC invocation-metadata gap is tracked in microsoft/durabletask-python#314.

The extension's BasicPython app currently has an unversioned azure-functions-durable requirement, which normally selects the stable release rather than opting into v2 previews. Keep the two transport/version scopes distinct; maintainers can resolve the stable-line dependency through a backport or an explicit migration to a fixed newer SDK, rather than treating this issue as the only current Python implementation.

Current behavior and source evidence

Verified on dev at badf8016eb8186958ebd07908576deb1bb33e945:

Reproduction and expected behavior

Construct a DurableOrchestrationClient with a known, valid invocation ID, capture or mock its outgoing HTTP requests, and invoke each purge API with valid arguments. The current call sites omit the ID even though the DELETE helper supports it. Both outgoing requests should carry X-Azure-Functions-InvocationId equal to the originating invocation ID; purge URLs, filters, response parsing, and error behavior should remain unchanged.

Acceptance Criteria

  • Both purge APIs pass the client's invocation ID to the existing DELETE helper.
  • Regression tests cover single-instance and filtered bulk purge and verify the actual outgoing header or the helper argument plus the existing transport-header contract.
  • Tests cover distinct invocation IDs and clients without an invocation ID; no ID is fabricated or leaked between clients.
  • Existing purge behavior remains unchanged apart from the correlation header.
  • Record the published SDK version containing the fix in this issue so the extension E2E dependency can be updated and its Python PurgeInstances exemption removed.

Related

This issue tracks the upstream SDK dependency only. Enabling mandatory extension E2E assertions follows after the fixed package is available.

主要语言
Python
星标
157
派生
71
30 天内没有已合并 PR

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Azure/azure-functions-durable-python 的其他 Issue

查看 Azure/azure-functions-durable-python 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。