feat: manually restart gate from REPL and TUI #17

Merged

haakon-e merged 1 commit from he/feat-manually-restart-gate-from into 1.1

2026-04-04 09:08:31 -07:00

haakon-e commented

2026-04-02 14:29:20 -07:00

(Migrated from github.com)

Summary

Add public Gate.restart() function for restarting the Julia session directly from the REPL, preserving the session ID so the TUI reconnects automatically
Add [r] restart keybinding on the Sessions tab alongside the existing [x] shutdown
Add guard-condition unit tests for Gate.restart()

Details

Gate.restart() follows the same structure as stop() (wait for the message-loop task, then cleanup) but calls _exec_restart instead of exiting. It sets _RESTARTING = true like the MCP :restart handler does to prevent the message-loop's finally block from racing with cleanup. No 0.3s sleep is needed since there's no ZMQ reply to flush.

The TUI restart handler sends send_restart! fire-and-forget but intentionally does not call stop_session! or remove the connection from the manager — execvp keeps the same PID and PTY, so the managed session stays valid and the health checker picks up the reconnected gate.

Closes #16

Test plan

From a connected REPL: Gate.restart() restarts the session and the TUI reconnects
Gate.restart() errors when the gate is not running
Gate.restart() errors when allow_restart=false
From the TUI Sessions tab: pressing r restarts the selected session
Agent-spawned sessions reconnect correctly after TUI restart
Unit tests pass: retest("Gate.restart")

## Summary - Add public `Gate.restart()` function for restarting the Julia session directly from the REPL, preserving the session ID so the TUI reconnects automatically - Add `[r] restart` keybinding on the Sessions tab alongside the existing `[x] shutdown` - Add guard-condition unit tests for `Gate.restart()` ## Details `Gate.restart()` follows the same structure as `stop()` (wait for the message-loop task, then cleanup) but calls `_exec_restart` instead of exiting. It sets `_RESTARTING = true` like the MCP `:restart` handler does to prevent the message-loop's `finally` block from racing with cleanup. No 0.3s sleep is needed since there's no ZMQ reply to flush. The TUI restart handler sends `send_restart!` fire-and-forget but intentionally does **not** call `stop_session!` or remove the connection from the manager — `execvp` keeps the same PID and PTY, so the managed session stays valid and the health checker picks up the reconnected gate. Closes #16 ## Test plan - [ ] From a connected REPL: `Gate.restart()` restarts the session and the TUI reconnects - [ ] `Gate.restart()` errors when the gate is not running - [ ] `Gate.restart()` errors when `allow_restart=false` - [ ] From the TUI Sessions tab: pressing `r` restarts the selected session - [ ] Agent-spawned sessions reconnect correctly after TUI restart - [ ] Unit tests pass: `retest("Gate.restart")`

haakon-e commented

2026-04-03 02:57:10 -07:00

(Migrated from github.com)

Testing locally (macOS), I can confirm restart appears to work both through TUI and directly through REPL.

One outstanding cosmetic issue:

Upon restart, it appears the REPL isn't flushed, see:

I would expect either:

flush the REPL (remove any existing output), or
(preferably) restart "below" the current output, to preserve view of history

*screenshot from antigravity terminal (vscode fork). Can't confirm if this persists with other terminals.

Testing locally (macOS), I can confirm restart appears to work both through TUI and directly through REPL. **One outstanding cosmetic issue:** Upon restart, it appears the REPL isn't flushed, see: <img width="661" height="244" alt="image" src="https://github.com/user-attachments/assets/3e14c3e1-60f3-4f5c-8ea8-28abd5887e0c" /> I would expect either: - flush the REPL (remove any existing output), or - (preferably) restart "below" the current output, to preserve view of history *screenshot from antigravity terminal (vscode fork). Can't confirm if this persists with other terminals.