t3 update, t3 connect and t3 service install fail with "exit code 1" after systemd's start limit trips, because nothing runs systemctl --user reset-failed #36319

What happened

After t3 update from 0.0.42 to 0.1.9, the background service was down. Running t3 connect and then t3 update again from the new 0.1.9 CLI both failed with Background setup failed while starting the service (exit code 1). The output gave no hint why the start failed or what to do next.

Diagnosis

There are two stacked problems. The first is already known.

1. The 0.0.42 t3 update wrote protocol 2 state for the protocol-3 launcher ([Bug]: t3 update across a service-launcher protocol bump leaves the service crash-looping ("Service state is invalid or unsupported") while reporting success #12627, fixed by fix(server): migrate compatible legacy service install state #19449 after v0.1.9). The launcher exited 1 five times and systemd hit StartLimitBurst=5 / StartLimitIntervalSec=300, leaving the unit failed.
2. Within the next 300s, the 0.1.9 t3 update rewrote the state file correctly ({"protocol": 3, "activeVersion": "0.1.9"}), and that file passes 0.1.9's decodeServiceState. But the systemd manager in apps/server/src/cloud/bootService.ts (activate / restart steps) only runs daemon-reload, enable and restart. It never runs systemctl --user reset-failed. systemd therefore refused every start with "Start request repeated too quickly". runStep reports only the exit code, so the user sees a generic BootServiceCommandError / CliUpdateError, even though the repair itself had already succeeded.

main still has no reset-failed, so after any start-limit hit the repair commands keep failing for up to 300s with an error that hides the cause. Noted in a #12627 comment; #19449 doesn't address it.

Suggested fix: run systemctl --user reset-failed t3code.service before starting or restarting in activate, restart and handoff. Optionally name "start-limit-hit" in the error (systemctl --user show -p Result).

Steps to reproduce

1. On Linux, install the systemd user service with t3 service install (the unit has StartLimitBurst=5, StartLimitIntervalSec=300, Restart=always, RestartSec=5).
2. Make the launcher fail at startup, e.g. set "protocol": 2 in ~/.t3/runtime/service-state.json and run systemctl --user restart t3code.service (or update from a 0.0.42 CLI, [Bug]: t3 update across a service-launcher protocol bump leaves the service crash-looping ("Service state is invalid or unsupported") while reporting success #12627).
3. Wait about 25s until systemctl --user status t3code.service shows "Start request repeated too quickly".
4. Within 300s of the first failure, repair the state with a 0.1.9 CLI: t3 update or t3 service install.
5. The command rewrites service-state.json correctly but fails with Background setup failed while starting the service (exit code 1). Running t3 connect gives the same error.

Version

0.1.9 (service and CLI). The failure started with a 0.0.42 to 0.1.9 t3 update.

Environment

Ubuntu 24.04.4 LTS, linux x64 (kernel 6.8.0-147), Node v26.12.1, background service as systemd user unit t3code.service

Evidence

# boot-service.log
[service-launcher] Service state is invalid or unsupported.   (x5, 19:40:02-19:40:23)
2026-11-13T19:40:33.315Z Background setup failed while starting the service (exit code 1).
2026-11-13T19:40:33.324Z Background setup failed while restarting the service after a failed update (exit code 1).
2026-11-13T19:40:52.954Z Background setup failed while starting the service (exit code 1).

# journalctl --user -u t3code.service
19:40:28 t3code.service: Start request repeated too quickly.
19:40:33 t3code.service: Start request repeated too quickly.   (t3 connect)
19:40:52 t3code.service: Start request repeated too quickly.   (t3 update from 0.1.9)

Related issues

#12627 covers the protocol 2 to 3 state mismatch that tripped the start limit; it's closed and fixed by #19449, which isn't in v0.1.9. This issue is separate: the missing reset-failed keeps the repair commands failing even after the state is fixed, and #19449 doesn't change that.

Fix applied or workaround

systemctl --user reset-failed t3code.service && rm -f ~/.t3/runtime/.service-stopping && systemctl --user start t3code.service. The service came up on 0.1.9 with NRestarts=0. That start ran outside the 300s window, so it doesn't prove reset-failed was needed then; it was needed for the starts at 19:40:33 and 19:40:52.

Filed by

Claude Code (Claude Opus 5.5, claude-opus-5-5) via t3 triage