Consumers die with CommitterIsDeadError on faststream 0.7.6 (fixed in 0.6.7)

[lesnik512]

Reported from production: every consumer stops processing, Sentry shows only

CommitterIsDeadError: Committer main task is not running
  File "faststream_concurrent_aiokafka/processing.py", line 115, in handle_task
    await self._committer.send_task(
  File "faststream_concurrent_aiokafka/batch_committer.py", line 235, in send_task
    self._check_is_commit_task_running()
  File "faststream_concurrent_aiokafka/batch_committer.py", line 84, in _check_is_commit_task_running
    raise CommitterIsDeadError(msg)

Those line numbers match 0.6.6 exactly.

Cause

FastStream 0.7.6 stopped re-exporting aiokafka's TopicPartition from faststream.kafka and
returns its own NamedTuple there:

faststream.kafka.TopicPartition	faststream.kafka.schemas.partition.TopicPartition
aiokafka.structs.TopicPartition	aiokafka.structs.TopicPartition
== / hash() equal	True
isinstance(fs_tp, ak_tp)	False

processing.py built commit keys from faststream.kafka.TopicPartition. Because the two compare
and hash equal, every dict lookup in the package still worked — only aiokafka's isinstance gate
in commit_structure_validate failed, raising TypeError: Key should be TopicPartition instance.

That TypeError is outside _call_committer's except (CommitFailedError, IllegalStateError) /
except KafkaError, so it escaped _commit_ready → _streaming_iteration →
_run_commit_process and killed the committer task on the first commit round. Every later message
then hit the send_task guard. No offsets were ever committed.

Reproduction

Running the released 0.6.6 test suite against faststream 0.7.6 with a real Redpanda broker:

9 failed, 180 passed

All nine failures are TypeError: Key should be TopicPartition instance. Differential:

Package	faststream	Result
0.6.6	0.7.6	committer dies, 0 offsets committed, next message raises CommitterIsDeadError
0.6.6	0.7.5	offsets commit, committer alive
0.6.7	0.7.6	offsets commit, committer alive

Ruled out

An earlier hypothesis blamed FastStream 0.7.6's broker-context refactor (self.config.fd_config.context
→ self.config.context). The refactor is real but behaviour-preserving: BrokerConfig.context
returns self.fd_config.context, the same ContextRepo. The 180 passing tests above include the
whole healthcheck suite, the lifecycle tests and the middleware context lookups — there were zero
context-related failures, and a context break would raise AttributeError/KeyError at startup
rather than TypeError at commit time.

Fix

#79 switched all four modules to aiokafka.structs.TopicPartition, released as 0.6.7.
0.6.8 additionally reports the cause of any committer death at ERROR (#82), so a future
occurrence of this class of failure arrives with its root cause attached instead of just the guard.

Affected versions

0.6.0 through 0.6.6 all import TopicPartition from faststream.kafka and declare
faststream[kafka]>=0.7.1,<0.8, so they resolve cleanly against faststream 0.7.6 and then fail on
the first commit. Upgrade to 0.6.8, or pin faststream[kafka]<0.7.6 if you cannot.

[lesnik512]

Fixed in 0.6.7 (#79) and improved in 0.6.8 (#82). Verified against what PyPI serves: a clean install now resolves 0.6.8 + faststream 0.7.6 and commits offsets normally.

Left open for a maintainer decision: 0.6.0-0.6.6 are still installable and unyanked, and their declared faststream[kafka]>=0.7.1,<0.8 range still resolves onto the broken combination.