Problem
et --attach <name> while the original et --name <name> client is still connected makes two client processes compete for the same client id and passkey. The attach steals the server connection, the original client's socket breaks, it immediately recovers and steals it back, and whichever client loses ends up with a decrypt failure that ends the session for both.
Server log signature on the losing side:
Finished recovering with socket fd: 15
Decrypt failed. Possible key mismatch?
Terminal session ended
The race resolves within ~100 ms, so the outcome flips run to run. It was found while bisecting a flaky test/system_tests/router_restart.sh (timed out waiting for 'ATTACH-first') on the named-sessions branch (MisterTea#793). Binary A/B swaps showed the same failure signature on both the pre- and post-cherry-pick heads, so it is inherent to attach, not a regression from any one commit.
Current mitigation
Only the test was changed: router_restart.sh now stops the first client and waits for it to exit before attaching (commit a3ca0d9 "Stop the first client before attaching in the router restart test"). The user-facing behavior is unchanged: attaching to a live session still tears it down.
Possible fixes
- Server-side handover: when a fresh client presents valid credentials for an id that already has a live connection, shut down the old connection cleanly and hand the session to the new one, so the old client exits instead of fighting back via recovery.
- Or client-side refusal: have
--attach detect that the saved record's client is still connected (heartbeat is already tracked for --list) and refuse with a clear message unless forced.
The handover option is closer to what users expect from named sessions (tmux-style attach).
Problem
et --attach <name>while the originalet --name <name>client is still connected makes two client processes compete for the same client id and passkey. The attach steals the server connection, the original client's socket breaks, it immediately recovers and steals it back, and whichever client loses ends up with a decrypt failure that ends the session for both.Server log signature on the losing side:
The race resolves within ~100 ms, so the outcome flips run to run. It was found while bisecting a flaky
test/system_tests/router_restart.sh(timed out waiting for 'ATTACH-first') on thenamed-sessionsbranch (MisterTea#793). Binary A/B swaps showed the same failure signature on both the pre- and post-cherry-pick heads, so it is inherent to attach, not a regression from any one commit.Current mitigation
Only the test was changed:
router_restart.shnow stops the first client and waits for it to exit before attaching (commit a3ca0d9 "Stop the first client before attaching in the router restart test"). The user-facing behavior is unchanged: attaching to a live session still tears it down.Possible fixes
--attachdetect that the saved record's client is still connected (heartbeat is already tracked for--list) and refuse with a clear message unless forced.The handover option is closer to what users expect from named sessions (tmux-style attach).