[Ehsan-hash]

Why

When the sender loop fails or is cancelled, concurrent requests can wait forever for a send that will never complete. Keep a terminal sender state so active, queued and later sends all finish.

What changed

• Propagate the original writer error to outstanding and later sends.
• Preserve cancellation during shutdown, including cancellation before the sender loop starts.
• Add sender lifecycle regressions and a two-request regression through Connection.

Scope

• Covers the private byte-stream sender and its callers; ordered graceful drain remains intact.
• No protocol, schema or transport API changes. Related to fix: drain pending futures on MessageSender loop termination #74, including the active and later sends that queue draining alone does not cover.

Blast Radius

Changes how pending sends terminate after writer failure or shutdown. Existing peer cancellation, stdio and HTTP/WebSocket tests pass.

Verification

• Unchanged source: 5 failed, 7 passed; fixed focused regressions: 12 passed.
• Affected RPC, cancellation, recovery and logging tests: 75 passed.
• make check passes; make test: 413 passed, 1 skipped on Python 3.12. The skipped Gemini integration was not enabled.

Developed and reviewed with AI assistance using Codex. No live model/provider calls were used for validation.

[frostming]

Suggested change

	self._set_terminal(ConnectionError("Sender closed"), cancel_pending=True)
	item.future.cancel()

It seems unnecessarily complicated, what does it do differently than this simple change?
send() needs to listen to a completeness flag of course.

[Ehsan-hash]

Thanks for reviewing this, @frostming. For the active send when the loop is cancelled, I agree that item.future.cancel() is sufficient.

With the terminal flag you mentioned, the remaining cases are cancelling the queued futures too, and detecting cancellation before _loop() starts (its exception handler never runs in that case, which is why there is a task-done callback). The writer-failure path separately preserves the original exception, such as BrokenPipeError, for active, queued and later sends instead of turning it into cancellation.

Those are the cases covered by the sender lifecycle regressions and the two-request connection regression. A simpler version using direct cancellation plus the terminal flag, queue cleanup and pre-start handling could preserve the same behaviour; the helper itself is not required.

[frostming]

ok, then we can add the _on_task_done callback to clear all pending futures.

[Ehsan-hash]

Thanks for the follow-up, @frostming. I'm closing this PR because I can't carry the proposed revision through validation and review. The patch and regression tests remain available if useful.

[frostming]

Thanks for the follow-up, @frostming. I'm closing this PR because I can't carry the proposed revision through validation and review. The patch and regression tests remain available if useful.

Thank you, I like simplicity instead of throwing a prompt to the agent and ask it to make the CI green. Codex especially likes to make things complicated. If you look at the effect of this class as a whole, you will find that #190 can accomplish the same thing, and the problem you mentioned does not exist.