Poison messages handling
维护者通常 3 天内回复
@sig5 已经在做这个了。
开始于 2024年9月24日。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 35/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- csharp
调研方向
首先追踪 PoisonMessageDetected 和 AbandoningMessage 的日志路径，并以 issue #1039 作为上下文。核实报告中 600ms 与 600s 的措辞差异，并确定应如何指定 poison-message 的 dequeue 限制和处置方式；当行为和可见性延迟消息与约定的处理方式一致时，即视为完成。
由索引模型根据 Issue 内容生成。
描述
As a rokochet of issue #1039 I've noticed that the message is being handled indefinitely.
I see the following traces in my logs:
PoisonMessageDetected: d8bdcf4d-ef40-4501-a99b-6e72309644ee: Message [TaskScheduled#1] with ID 6128efd4-8904-494d-9a2d-d2d8d01edbe7 has been dequeued 79 times and is now considered poison: {"Account":"...","TaskHub":"Services","...":"TaskScheduled","TaskEventId":1,"MessageId":"6128efd4-8904-494d-9a2d-d2d8d01edbe7","InstanceId":"d8bdcf4d-ef40-4501-a99b-6e72309644ee","ExecutionId":"b27db20915cf4e5db6cad3589dde88df","PartitionId":"...-workitems","DequeueCount":79}
AbandoningMessage: d8bdcf4d-ef40-4501-a99b-6e72309644ee: Abandoning [TaskScheduled#1] message back to ...-workitems and setting a visibility delay of 600ms: {"Account":"...","TaskHub":"...","EventType":"TaskScheduled","TaskEventId":1,"MessageId":"6128efd4-8904-494d-9a2d-d2d8d01edbe7","InstanceId":"d8bdcf4d-ef40-4501-a99b-6e72309644ee","ExecutionId":"b27db20915cf4e5db6cad3589dde88df","PartitionId":"services-workitems","SequenceNumber":208,"PopReceipt":"AgAAAAMAAAAAAAAAxVkNR+xc2gE=","VisibilityTimeoutSeconds":600}
Side note: the message say
setting a visibility delay of 600ms, while the code actually delays for 600s (not ms).
Notice the DequeueCount value of 79 (I've seen values much higher). Perhaps there should be a setting that controls the maximum number of dequeues attempts, after which the message should just be disposed?
@cgillum @davidmrdavid
- 主要语言
- C#
- 星标
- 1.7k
- 派生
- 338
- 平均合并
- 4 天 13 小时
- 30 天内合并 PR
- 10
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Azure/durabletask 的其他 Issue
-
AzureStorage: a permanent history-load failure in ScheduleOrchestrationStatePrefetch increases memory without limit可能已有人在做 @saurav2104 于 1 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 35/100
Azure/durabletask#1419 · 3 条评论 ·
维护者通常 3 天内回复
-
Azure Storage backend: ExecutionTerminated message is never deleted when the Instances row is absent, causing permanent control-queue poison (regression in 2.7.0 from #1256)可能已有人在做 @sean0407 于 5 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 55/100
Azure/durabletask#1398 · 2 条评论 ·
维护者通常 3 天内回复
-
Azure Storage backend: control queue partition left unowned for hours/days after lease expires可能重新可做 @nytian 于 46 天前认领，目前没有进行中的 PR。 未关闭
Azure/durabletask#1389 · 1 条评论 · 已指派 1 人 ·
维护者通常 3 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
Azure/durabletask#1332 ·
维护者通常 3 天内回复
-
难度 3/5 1-2 天 新手友好度 58/100
Azure/durabletask#1318 · 1 条评论 ·
维护者通常 3 天内回复
查看 Azure/durabletask 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
维护者通常 1 天内回复
-
dette technique priorité: basse zone: service
难度 2/5 1-3 小时 新手友好度 68/100
damiensabau/nexus-lobby#25 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
sebastienros/jint#4282 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 76/100
pyrevitlabs/pyRevit#3792 ·
维护者通常 1 天内回复