Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

RabbitMQ subscription never reports transport death to the supervisor

オープン
  • 何か問題がありますか？
#575 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 7 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
1〜2日
初心者へのやさしさ
53/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
csharp, rabbitmq
領域
backend

調査の方向性

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.ChannelShutdownAsync
  • IConnection.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

  1. treat any shutdown as a drop and let the supervisor own recovery (simple, predictable, matches the other transports), or
  2. 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時間
マージ済み PR（30日）
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Eventuous/eventuous のほかの issue

Eventuous/eventuous の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。