RabbitMQ subscription never reports transport death to the supervisor
维护者通常 7 天内回复
还没有人认领这个 Issue。
评估
调研方向
Read the subscription lifecycle changes in #571 and inspect RabbitMqSubscription.Connect, especially how other transports map shutdown events to run.Fail. Trace the RabbitMQ channel, connection, and consumer shutdown signals and decide how automatic recovery should interact with supervisor resubscription. Done means transport death is reported once, clean teardown is not reported as a drop, and the behavior is covered for the relevant shutdown cases.
由索引模型根据 Issue 内容生成。
描述
Context
#571 rebuilt the subscription lifecycle around a supervisor loop: each connect attempt gets a SubscriptionRun, and a transport signals its death via run.Fail(...) so the supervisor can tear the run down and resubscribe. Every transport follows this contract except RabbitMQ.
RabbitMqSubscription.Connect wires only consumer.ReceivedAsync. Consumer cancellation, channel shutdown, and connection shutdown are never mapped to run.Fail, so when the broker cancels the consumer or the channel/connection dies for good (notably with automatic recovery disabled, or when recovery gives up), run.Ended never completes: the supervisor stays parked, no drop is reported, health stays green, and the subscription consumes nothing until the host restarts.
This is not a regression from #571 — the previous implementation never called Dropped for RabbitMQ either, which is why it was split out of that PR (it surfaced during its review). c061dd79 in #571 fixed the adjacent case of handler failures being swallowed under ThrowOnError; this issue covers transport-level death.
Suggested direction
In Connect, map the client's shutdown signals to the run:
IChannel.ChannelShutdownAsyncIConnection.ConnectionShutdownAsync- consumer cancellation/unregistration on
AsyncEventingBasicConsumer
each calling run.Fail(DropReason.ServerError, ...) — but only when the shutdown isn't the run's own teardown (guard on run.Token.IsCancellationRequested, as the other transports do), so a clean stop isn't double-reported.
The interaction with the client's automatic recovery (on by default in ConnectionFactory) needs a decision: a recoverable shutdown may be healed by the client without a resubscribe, so either
- treat any shutdown as a drop and let the supervisor own recovery (simple, predictable, matches the other transports), or
- only fail the run on shutdowns the client reports as non-recoverable, and keep relying on auto-recovery for the rest.
Option 1 is likely the right default; relying on auto-recovery means the supervisor never learns the transport flapped, and per-run state (sequence, checkpoint handler) silently spans reconnects.
Refs: #571
- 主要语言
- C#
- 星标
- 512
- 派生
- 99
- 平均合并
- 5 天 6 小时
- 30 天内合并 PR
- 5
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Eventuous/eventuous 的其他 Issue
-
MongoDB integration tests fail on newer GitHub Actions runner kernels可能已有人在做 @nmummau 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 74/100
Eventuous/eventuous#626 · 2 条评论 ·
维护者通常 7 天内回复
-
`dotnet format style --verify-no-changes` fails with naming violations and unnecessary imports可能已有人在做 @nmummau 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 80/100
Eventuous/eventuous#624 · 1 条评论 ·
维护者通常 7 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
Eventuous/eventuous#627 · 1 条评论 ·
维护者通常 7 天内回复
-
SQL Server: `append_events` does not need the `@inserted` table variable可能已有人在做 @nmummau 于 8 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 20/100
Eventuous/eventuous#619 · 1 条评论 ·
维护者通常 7 天内回复
-
SQL Server: stream reads do one key lookup per event, and `IDX_EventsStream` duplicates `UQ_StreamIdAndStreamPosition`可能已有人在做 @nmummau 于 8 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 18/100
Eventuous/eventuous#618 · 1 条评论 ·
维护者通常 7 天内回复
查看 Eventuous/eventuous 的全部 Issue
相似的 Issue
-
area: client bug
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
bug mcp misleading small
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
Bug Platform: Android
难度 2/5 1-3 小时 新手友好度 78/100
getsentry/sentry-dotnet#5764 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
microsoft/SimpleL7Proxy#287 ·
维护者通常 1 天内回复