Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

RabbitMQ subscription never reports transport death to the supervisor

Aperta
  • Qualcosa non va?
#575 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 7 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
53/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
csharp, rabbitmq
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
C#
Stelle
512
Fork
99
Merge medio
5g 6h
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Eventuous/eventuous

Tutte le issue di Eventuous/eventuous

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.