eblume/hephaestus
1
0
Fork 0
generated from eblume/project-template
Code Issues Pull requests 1 Projects Releases 14 Packages Wiki Activity Actions
hephaestus/docs/changelog.d/client-reconnect.bugfix.md
Erich Blume b04a71421e
All checks were successful
Build / validate (pull_request) Successful in 8m7s
Details
fix(hephd): reconnect the socket client across daemon restarts 
`Client` connected to the unix socket once and never reconnected, so after an
opt-in self-update or `heph daemon restart` dropped the socket, every later
`call()` failed — `heph-tui` would sit on errors until relaunched (and the work
we just shipped makes restarts more frequent).

`Client` now stores the socket path and reconnects on a dropped connection,
classifying the failure to stay safe:
- write-side failure (request never reached the daemon) → reconnect + retry once;
- reply lost after sending (daemon closed mid-request) → reconnect for next time
  but surface this one, so a mutation is never silently double-applied;
- genuine RPC errors are passed through untouched.

heph-tui and the CLI use `Client` unchanged, so the TUI self-heals on its next
refresh tick. Adds an integration test driving a mock daemon that drops the
connection after each request.

Closes the "heph-tui: reconnect on a dropped daemon socket" backlog task.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-08 15:19:10 -07:00

534 B
Raw Permalink Blame History

The heph CLI and heph-tui now survive a daemon restart. Previously the unix-socket client connected once and never reconnected, so an opt-in self-update or heph daemon restart left every subsequent call failing — heph-tui would sit on errors until relaunched. The client now reconnects on a dropped socket: a request that never went out is retried transparently, while a reply lost mid-request is surfaced (not silently retried) so a mutation is never double-applied. A long-running TUI self-heals on its next refresh tick.