Desktop app update gets stuck forever; terminal shows hermes:api ECONNREFUSED 127.0.0.1:9120 on Fedora Wayland

[nichsedge]

Bug description

When I open Hermes Desktop and trigger an update from inside the desktop app, the app appears to stay in an "updating" state forever instead of cleanly finishing and returning to a usable UI.

At the same time, the terminal shows this error:

Error occurred in handler for 'hermes:api': Error: connect ECONNREFUSED 127.0.0.1:9120
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1645:16) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 9120
}
[26228:0603/082334.983571:ERROR:ui/ozone/platform/wayland/host/wayland_frame_manager.cc:662] The server has buggy presentation feedback. Discarding all presentation feedback requests in all frames except the last 3.

Steps to reproduce

1. Launch Hermes Desktop.
2. Use the in-app update flow.
3. Wait for the desktop app to finish updating.
4. Observe that the UI keeps showing an updating/loading state instead of completing normally.
5. Check the terminal that launched Hermes Desktop.

Expected behavior

After the update finishes, Hermes Desktop should either:

• reconnect automatically to the updated backend and return to the normal UI, or
• clearly prompt for a restart and stop the update flow.

It should not remain in an apparent endless updating state.

Actual behavior

• The desktop UI appears stuck updating forever.
• The terminal shows connect ECONNREFUSED 127.0.0.1:9120 from the hermes:api handler.
• Wayland also logs a presentation feedback warning.

Additional observations

I checked the local Hermes logs after the failure.

~/.hermes/logs/desktop.log shows the update itself completing successfully, including these lines:

[hermes] [updates] done: Backend updated. Restart Hermes to load the new version.
[hermes] [boot] Resolving Hermes backend
[hermes] [boot] Finding an open local port
[hermes] [boot] Resolving Hermes runtime
[hermes] [boot] Hermes runtime is ready
[hermes] [boot] Starting Hermes backend via Hermes at /home/al/.hermes/hermes-agent (venv: /home/al/.hermes/hermes-agent/venv)
[hermes] [boot] Waiting for Hermes backend to become ready
[hermes] [boot] Hermes backend is ready. Finalizing desktop startup

The same log also shows that during update it stopped a dashboard/backend process:

[hermes] [updates] update: ⟲ Stopping 1 dashboard process(es) (the running backend no longer matches the updated frontend)
[hermes] [updates] update: ✓ stopped PID 26361

~/.hermes/logs/update.log also reports a successful update completion.

So from the logs, the update/build path looks successful, but the desktop app UI still ends up stuck while hermes:api is trying to connect to 127.0.0.1:9120 and gets ECONNREFUSED.

Environment

• Hermes CLI/Desktop version: Hermes Agent v0.15.1 (2026.5.29)
• Desktop package version: apps/desktop/package.json = 0.15.1
• Hermes repo commit after update: 54343bcade7cc1205cea0637cfffcf925f097c02
• OS: Fedora Linux 44 (Workstation Edition)
• Kernel: Linux fedora 7.0.10-201.fc44.x86_64
• Session type: wayland
• Desktop environment: GNOME
• Wayland display: wayland-0
• CPU: AMD Ryzen 5 5500U with Radeon Graphics
• Memory: 10 GiB RAM

Raw system info

date: 2026-06-03T08:31:32+07:00
uname: Linux fedora 7.0.10-201.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Wed May 27 13:57:41 UTC 2026 x86_64 GNU/Linux
NAME="Fedora Linux"
VERSION="44 (Workstation Edition)"
VERSION_ID=44
PRETTY_NAME="Fedora Linux 44 (Workstation Edition)"
arch: x86_64
session_type: wayland
desktop: GNOME
wayland_display: wayland-0
display: :0

Possible relevance

The refused port is 127.0.0.1:9120. That may be related to the dashboard/backend handoff during desktop update/restart, but I have not verified the exact root cause.

[teknium1]

Thanks for the detailed logs and the linked follow-up investigation. This is an automated hermes-sweeper review; the reported stuck-update behavior is now implemented on current main.

• e5e25836350a7041e58bb4ecfd55cba893630df4 (fix(desktop): relaunch on Linux after in-app update instead of hanging, merged via fix(desktop): relaunch on Linux after in-app update instead of hanging #45205) is an ancestor of current main.
• apps/desktop/electron/main.ts:2879 selects either a Linux relaunch handoff or a completed guiSkew state for AppImage/.deb/.rpm/dev paths.
• apps/desktop/src/store/updates.ts:392 ensures every completed non-handoff update reaches a closeable terminal state or closes the overlay; it no longer leaves applying true indefinitely.
• apps/desktop/src/store/updates.test.ts:324 covers the Linux GUI/backend-skew terminal state and asserts applying is false.

The earlier linked PR #37834 identified the same symptom; its precise 'done'-stage patch was superseded by the broader merged Linux completion-state fix.