Fix panic when closing the last buffer #42
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/042-fix-panic-when-closing-the-last-buffer"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fix panic when closing the last buffer
Along the way:
Touches 30 files:
Cargo.lock,Cargo.toml,ck-mcp-bridge/Cargo.toml,ck-mcp-bridge/src/main.rs,ck-mcp-bridge/tests/bridge_pumps_bytes.rs,ck-terminal/src/pty.rsand 24 more.Two things inline. The one in
ck-mcp-bridge/tests/bridge_pumps_bytes.rsis the one I care about.@ -0,0 +52,4 @@// the bridge, write SERVER_TO_CLIENT back. This stands in for the// bus's rmcp::Server serving a tool call.let server_handle = tokio::spawn(async move {let (mut stream, _) = listener.accept().await.unwrap();acceptunwraps here. If this is reachable from user input it is a panic in front of a person rather than an error they can read. Is it provably there at this point, or should it carry a??@ -0,0 +52,4 @@let Some(ctx) = project.contexts.get(&id) else {return;};ctx.kind.clone()cloneis cloned on what looks like a hot path. Is the ownership forced here, or can this borrow?@ -0,0 +91,4 @@loop {drain_requests(&mut bus.receiver, coord, buffers);if task.is_finished() {return task.await.expect("task panicked");The expect message on
expectis the only thing a user sees if this fires. Does it say what they should do, or only what we assumed?, at ckeditor/tests/scenarios/mcp_bridge_end_to_end.rs:94.It is reachable. The function in
ck-mcp-bridge/tests/bridge_pumps_bytes.rsreturns a Result now and the caller reports it, so the unwrap onacceptis gone.It can borrow. The clone of
clonewas left over from before the lifetime was threaded throughckeditor/src/app_layout/context_switch.rs, and it is gone.It said what I assumed. Reworded in
ckeditor/tests/scenarios/mcp_bridge_end_to_end.rsso it names the input that broke it, which is what the bug report will need.Updated. The point about
ck-mcp-bridge/tests/bridge_pumps_bytes.rsturned out to be a real bug, so thank you.Read it too. No objection to
ck-mcp-bridge/tests/bridge_pumps_bytes.rs.That is it for
ck-mcp-bridge/tests/bridge_pumps_bytes.rs. Thanks for the second pass.Smoke-tested against real `claude` 2.1.114 against a live McpBus. Found and fixed two bugs PR 4 couldn't catch without the real client: 1. Config path. PR 4 wrote `.claude/mcp.json`. The real claude CLI only discovers `.mcp.json` at the project root — confirmed by `claude mcp add --scope project` (writes there) and `claude mcp list` (reads only there; our `.claude/mcp.json` produced zero hits). Changed `ensure_mcp_json` to write `<context.root>/.mcp.json`. 2. Config schema. PR 4 emitted `{"command", "env"}` only. Real claude accepted that for health-check but drifts from `claude mcp add`'s canonical output (`{"type": "stdio", "command", "args", "env"}`). Added `type: "stdio"` and `args: []` so we stay byte-identical to claude's own writer — defends against future schema validators. New scenario `mcp_claude_cli_health_check` runs `claude mcp list` against a live bus and asserts "ckeditor: <bridge> - ✓ Connected". Skipped when `claude` is not on $PATH (CI without it stays green). Verified output on this machine: ckeditor: .../target/debug/ck-mcp-bridge - ✓ Connected