`_commit_ready`'s success flag is computed, tested, and then discarded by its only caller

[lesnik512]

_commit_ready returns all(results) — false when any _call_committer in the round failed
(batch_committer.py:117). Its only production caller drops it on the floor
(batch_committer.py:174-187):

committed = False
if decision.should_commit:
    ready = self._pending.take_ready()
    if ready:
        await self._commit_ready(ready)   # return value discarded
        committed = True

self._scheduler.note_committed(
    now=loop.time(), committed=committed,
    timeout_fired=decision.timeout_fired, pending_empty=not self._pending,
)

So committed means "a round was attempted", not "a round succeeded". The tests do pin the flag
(test_commit_ready_returns_false_on_commit_failure, test_kafka_committer.py:725), which makes
the discard easy to misread as an oversight.

Where it could actually matter

committed only feeds the deadline re-arm in note_committed
(_commit_scheduler.py:93-95):

if committed or timeout_fired:
    self._timeout_deadline = (now + self._batch_timeout) if not pending_empty else None

In the common failure shapes it makes no difference. A KafkaError re-queues the batch and a
CommitFailedError discards it; either way pending drains, pending_empty is true, and the
deadline is cleared to None whichever value committed held.

The one shape where it diverges is a partially-ready multi-partition round: take_ready()
lifted the ready prefixes, the commit for them failed, and pending still holds unfinished tasks on
other partitions. committed=True then pushes the deadline out a full commit_batch_timeout_sec
even though nothing was committed, delaying the next attempt for work that is already finished.

Why the obvious fix is probably wrong

Passing committed=all(results) through means that on a failed round with pending non-empty,
neither committed nor timeout_fired is set, so the branch is skipped and _timeout_deadline
keeps its old, now-past value. wait_timeout then returns zero or negative every iteration and
the loop spins — the same busy-retry failure mode #62 documents as the reason its own obvious fix
was rejected. Any real fix has to distinguish "retry promptly" from "back off", which is the
retry-with-backoff feature #62 also lands on.

Where this came from

Noticed while fixing #82 (committer death reporting) and deliberately left out of that PR's scope.
Not a cause of, and not related to, the CommitterIsDeadError incident in #83.

Triage question: is the discard deliberate — holding the "pending empty ⇒ deadline None"
invariant and avoiding a stale past deadline — or is the partially-ready case a real delay worth
fixing? If deliberate, a sentence in _streaming_iteration saying so would stop the next reader
re-filing this. If it is bundled into any future retry-with-backoff work, fold it in with #62.

[lesnik512]

Triage: not a defect. Both hypotheses in the issue body are wrong, by measurement.

I tested the two claims rather than reasoning further. Harnesses drove the real committer loop.

Claim 1 — "a failed round delays the retry by a full commit_batch_timeout_sec"

Not reproduced. Two partitions, one ready and one in-flight, commit_batch_size=2,
commit_batch_timeout_sec=1.0, first commit raises KafkaError:

failed round at  +0.00s
retry committed  +0.00s after the failure
offsets committed: [{TopicPartition(topic='t', partition=0): 2}]

The retry is immediate. _call_committer re-queues the batch onto _messages_queue, which makes
queue_get fire on the next iteration; the re-absorbed task puts pending_len back at
batch_size, so should_commit fires again from the size trigger. The deadline never enters into
it. The divergence I described needs the round to be size-triggered and the re-queue not to
restore the size trigger, which the re-queue path itself prevents.

Claim 2 — "passing all(results) through leaves a stale past deadline and spins the loop"

Also not reproduced. CommitFailedError (discard, no re-queue), commit_batch_size=1,
commit_batch_timeout_sec=5.0, counting _streaming_iteration calls over 1s idle:

	pending empty	_timeout_deadline	idle iterations in 1.0s
current code	True	None	0
with committed = all(results)	True	986110.97 (armed)	0

No spin either way. The leftover deadline sits in the future, not the past, and if it ever
elapses while pending is empty then timeout_fired goes true on the next evaluate and the branch
clears it. It self-corrects.

What the measurement does show

The right-hand column is the real finding: with the "fix" applied, the scheduler ends a failed
round with pending empty and the deadline still armed, breaking the documented invariant at
_commit_scheduler.py:23-28 (pending empty ⇒ deadline None). The next absorbed task then
inherits the leftover deadline instead of arming a fresh one, making scheduler state depend on
history. Current behaviour holds the invariant.

So committed=True is doing the right thing. It means "a commit round ran, so re-base the
deadline" — which is exactly what the scheduler needs — and passing commit success through
would be wrong.

Disposition

Closing as wontfix: the behaviour is correct and the obvious change is a regression.

What remains is cosmetic but is what generated this issue and will generate it again: the local is
named committed while meaning "a round ran", and _commit_ready's bool return is genuinely
dead in production — asserted only by test_commit_ready_returns_false_on_commit_failure, and
dropped by its one caller. Renaming the local to something like round_ran, and either consuming
or dropping the return value, would settle it permanently. Happy to do that as a small PR if you
want it; not doing it unasked, since it is churn on correct code.