cli: cover the bridge's stdout-loss path #232

Merged

natsukium merged 1 commit from issue-166 into main 2026-09-08 21:56:47 +09:00

Conversation 0 Commits 1 Files changed 1 +92 -46

natsukium commented 2026-09-08 20:51:40 +09:00

Owner

Copy link

The golden felis bridge conversations cover the clean terminal, the failing terminal before the first item, cancel, and daemon loss, but stdout loss is not among them — and it cannot be: the channel that would carry a correlated error is the one that failed, so the bridge publishes nothing and there is no transcript to diff. This lands it as a plain assertion test beside the goldens rather than extending the fixture format with a reader-closing directive.

The bridge harness gains close_stdout (dropping the read end is the only way to fail a child's stdout from outside) and an exit path that leaves stdin open, so a status can only come from the bridge's own decision. The new test serves one reply, parks the daemon mid-verb so a second operation is genuinely in flight, closes the read end, and asserts exit 1, that the served reply is all stdout ever carried, and that stderr stays human-only. Removing the close_stdout call makes it hang and fail, so it is not vacuous. The pre-existing stdout_failure_stops_the_bridge_without_waiting_for_stdin_eof case moves onto the same harness and gains the stderr assertion it previously discarded with Stdio::null().

Test-only; no documented behavior changes, so no doc or CHANGELOG cascade.

Fixes #166

The golden `felis bridge` conversations cover the clean terminal, the failing terminal before the first item, cancel, and daemon loss, but stdout loss is not among them — and it cannot be: the channel that would carry a correlated error is the one that failed, so the bridge publishes nothing and there is no transcript to diff. This lands it as a plain assertion test beside the goldens rather than extending the fixture format with a reader-closing directive. The bridge harness gains `close_stdout` (dropping the read end is the only way to fail a child's stdout from outside) and an exit path that leaves stdin open, so a status can only come from the bridge's own decision. The new test serves one reply, parks the daemon mid-verb so a second operation is genuinely in flight, closes the read end, and asserts exit `1`, that the served reply is all stdout ever carried, and that stderr stays human-only. Removing the `close_stdout` call makes it hang and fail, so it is not vacuous. The pre-existing `stdout_failure_stops_the_bridge_without_waiting_for_stdin_eof` case moves onto the same harness and gains the stderr assertion it previously discarded with `Stdio::null()`. Test-only; no documented behavior changes, so no doc or CHANGELOG cascade. Fixes #166

natsukium added 1 commit 2026-09-08 20:51:40 +09:00

cli: pin the bridge's stdout loss under an in-flight operation ... e390789ee5

The golden bridge conversations cover every terminal path, but a stdout
loss has no terminal: the channel that would carry a correlated error is
the one that failed, so the bridge stops every operation and exits 1 with
nothing on stdout. That shape cannot be diffed as a transcript, so it is
a plain assertion test rather than a fixture directive for closing the
reader.

The existing coverage closed the reader before the bridge had written
anything and ignored stderr. Closing it while the daemon is parked mid-
verb puts a real operation in flight at the moment stdout dies, and
capturing stderr pins that the failure stays human-only there instead of
leaking a protocol object onto the one channel still open.

Assisted-by: Claude Code

natsukium merged commit c40a673d76 into main 2026-09-08 21:56:47 +09:00

natsukium deleted branch issue-166 2026-09-08 21:56:47 +09:00

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

priority/P0

Must be resolved before the v0.1.0 tag

  

priority/P1

Must be settled before the first public contract freezes

  

priority/P2

Explicitly deferred until after v0.1.0

  

release/v0.1.0

Work tracked for the first tagged release

  

status/blocked

Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  

status/planned

Triaged with a source-grounded plan and a passed pi review; ready to implement

  

type/bug

Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  

type/design

An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  

type/test-gap

Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  

type/tracker

Parent issue that tracks child work

No labels

priority/P0

priority/P1

priority/P2

release/v0.1.0

status/blocked

status/planned

type/bug

type/design

type/test-gap

type/tracker

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

natsukium/felis!232

No description provided.