fix(server): keep a failed service start out of the current state

[vitalyiegorov]

Problem

Fixes #12197. On macOS 15 the first t3 service install can fail at launchctl bootstrap (#11995). By then the plist, service-state.json and runtime already name the new version, and nothing records the failed start. The retry prints T3 Code service is already installed and exits 0 while launchd keeps running the previous launcher, so every remote update stays blocked by the #11940 protocol gate.

Change

BootService.install in apps/server/src/cloud/bootService.ts now writes the existing .restart-pending marker on every install, not only for start: false. It's one removed conditional. A successful activate still removes the marker, and so do restart and the launcher when it comes up on that version. A failed start therefore leaves status reporting restart-pending, and the next install repairs the service instead of calling itself current.

This complements #12005, which makes the stop and start actually replace the job. This PR only makes the retry honest.

Scope and approval

Julius triaged #12197 as a real bug, separate from #11995, and labelled it accepted: #12197 (comment)

Verification

• New test: on launchd, a started install whose launchctl bootstrap fails leaves the marker with the CLI version. status then reports problems: ["restart-pending"] with current: false. A second install (what reconcileService does for a status that isn't current) runs bootout, enable and bootstrap again and removes the marker.
• The systemd install test also asserts that a successful started install leaves no marker.
• vp test run apps/server/src/cloud/bootService.test.ts: 39 passed, after rebasing on current main. Server typecheck, plus lint and format on the touched files.
• Reproduced and diagnosed on a Mac Studio running macOS 15.7.4, where the old npm launcher was still loaded under the new plist.
• No UI changes.

Implemented with Claude Fable 5.1 and Claude Opus 5 in T3 Code (Claude Code harness).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 2a55165

Macroscope's review found this PR approvable — This is a narrow service-install recovery fix that preserves the marker when activation fails, preventing a failed start from being reported as current and enabling a later retry. Successful installs still remove the marker, and targeted regression tests cover the failure and recovery flow.

No code changes detected at e8751ed. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 2c6de1e2-d3da-4467-8757-24114bfdddb5

📥 Commits

Reviewing files that changed from the base of the PR and between cb1e33b2c57ab402c612f163be5c8c22603ce6f8 and de4a8db.

📒 Files selected for processing (2)

• apps/server/src/cloud/bootService.test.ts
• apps/server/src/cloud/bootService.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The install flow now writes a restart-pending marker before service updates and removes it after successful activation. macOS tests verify failed launch-agent startup remains non-current and that a later install repairs the service.

Changes

Restart-pending recovery

Layer / File(s)	Summary
Install marker and recovery flow apps/server/src/cloud/bootService.ts, apps/server/src/cloud/bootService.test.ts	install() writes the restart-pending marker before service updates. Failed macOS launch-agent startup leaves the marker and reports restart-pending; a successful retry removes it and reports the service as current.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant BootService.install
  participant launchctl
  participant BootService.status
  BootService.install->>BootService.install: Write SERVICE_RESTART_PENDING_FILE
  BootService.install->>launchctl: Bootstrap launch agent
  launchctl-->>BootService.install: Startup failure
  BootService.install->>BootService.status: Read restart-pending state
  BootService.status-->>BootService.install: Report restart-pending and not current
  BootService.install->>launchctl: Bootout, enable, and bootstrap
  launchctl-->>BootService.install: Startup succeeds
  BootService.install->>BootService.install: Remove SERVICE_RESTART_PENDING_FILE

Loading

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to de4a8

The recovery behavior preserves pending state until activation succeeds and correctly retries failed service updates. The change is ready to merge.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	For #12197, BootService.install writes .restart-pending before each install. The tests verify that a failed launchctl bootstrap preserves the marker, that status reports restart-pending with…
Out of Scope Changes check	✅ Passed	The production change updates restart-pending tracking during service installation. The tests cover marker cleanup, launchd bootstrap failure, status reporting, and retry behavior. These changes direc…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2…
Title check	✅ Passed	The title clearly identifies the main change: preventing a failed service start from being reported as current.
Description check	✅ Passed	The description covers the problem, change, scope and approval, and verification. It gives focused test results and notes the platform-specific reproduction.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

_{Comment @coderabbitai help to get the list of available commands.}