Repository navigation
FastStream health check pings only the first broker of a multi-broker app #293
Description
FastStreamHealthChecksInstrument._define_health_status pings config.application.broker and nothing else (lite_bootstrap/bootstrappers/faststream_bootstrapper.py:110). In FastStream that property returns self.brokers[0]. An app that holds more than one broker, for example through add_broker in FastStream 0.7, reports healthy while every broker after the first is down.
Services that need the other brokers checked set health_checks_enabled=False and mount their own route, which drops the OpenTelemetry span and response format the built-in check provides.
Proposal
Ping every broker in config.application.brokers and report healthy only when all of them answer. brokers exists from FastStream 0.6, so this works across the current faststream>=0.6 floor. Running the pings concurrently keeps the total wait within faststream_health_check_broker_timeout.
Acceptance
- An app with two brokers where the second fails its ping gets a 500 from the health route.
- An app with one broker behaves as it does now.
Activity
lesnik512 commentedon Oct 20, 2026
Agent Brief
Category: bug
Summary: The FastStream health check must ping every broker the app holds, not only the first.
Verified: I built an
AsgiFastStreamwith twoRedisBrokers (the second added withadd_broker), patched the first broker'spingto returnTrueand the second's to returnFalse, and called the health route. It returned 200, and the second broker'spingwas never called.Current behavior:
The FastStream health check pings only
application.broker, which FastStream defines asbrokers[0]. An app with several brokers reports healthy while any broker after the first is down. An app with no broker reports unhealthy.Desired behavior:
The health check pings every broker in
application.brokersand reports healthy only when all of them answerTrue. The pings run concurrently, each withfaststream_health_check_broker_timeout, so the route's total wait stays within one timeout rather than one per broker. An app with no brokers still reports unhealthy. The response bodies and status codes for the healthy and unhealthy cases stay as they are.Key interfaces:
FastStreamHealthChecksInstrument: the method that decides health status readsapplication.brokersinstead ofapplication.broker.FastStreamConfig.faststream_health_check_broker_timeout: unchanged, applied to each ping.application.brokersexists from FastStream 0.6, so thefaststream>=0.6floor stays.Acceptance criteria:
pingreturnsFalse, the health route returns 500.True, the health route returns 200, and each broker'spingis called once with the configured timeout.Out of scope: