fix: route new-session launch through managed opencode lifecycle #396

Merged

dries merged 1 commit from fix-managed-launch-newsession into main

2026-07-19 23:20:27 +02:00

dries commented

2026-07-19 18:57:26 +02:00

Owner

Closes the last open acceptance criterion of #376 (AC-3: manual and automatic launch paths cannot create competing managed instances).

The managed lifecycle (worktree / MCP new_session / same-dir sessions) already routed through EnsureProjectOpencode and was guarded by singleflight + the managed registry. But the manual new-session bootstrap — POST /api/tmux/launch-opencode, called by the frontend new-session flow — still ran the raw tmux.LaunchOpencode (opencode --port 0) outside that guard, so a user-driven launch could race an ensure and spawn a second competing instance for one project.

Change

handleTmuxLaunchOpencode now delegates to EnsureProjectOpencode instead of LaunchTmux, so every launch path shares the singleflight guard and managed registry. The response session field now carries the managed runtime's instance ID (the tmux session name for the native runtime), preserving wire compatibility.
Updated the handler regression test to prove the routing goes through EnsureProjectOpencode.
Refreshed the createSessionWithLaunch doc comment.

The LaunchTmux host method + gRPC seam are left in place (still part of the remote plumbing); only the HTTP handler's target changed.

Closes the last open acceptance criterion of #376 (AC-3: manual and automatic launch paths cannot create competing managed instances). The managed lifecycle (worktree / MCP `new_session` / same-dir sessions) already routed through `EnsureProjectOpencode` and was guarded by singleflight + the managed registry. But the manual new-session bootstrap — `POST /api/tmux/launch-opencode`, called by the frontend new-session flow — still ran the raw `tmux.LaunchOpencode` (`opencode --port 0`) outside that guard, so a user-driven launch could race an ensure and spawn a second competing instance for one project. ## Change - `handleTmuxLaunchOpencode` now delegates to `EnsureProjectOpencode` instead of `LaunchTmux`, so every launch path shares the singleflight guard and managed registry. The response `session` field now carries the managed runtime's instance ID (the tmux session name for the native runtime), preserving wire compatibility. - Updated the handler regression test to prove the routing goes through `EnsureProjectOpencode`. - Refreshed the `createSessionWithLaunch` doc comment. The `LaunchTmux` host method + gRPC seam are left in place (still part of the remote plumbing); only the HTTP handler's target changed.

dries added 1 commit

2026-07-19 18:57:26 +02:00

fix: route new-session launch through managed opencode lifecycle

CI / Build Desktop (macOS arm64) (pull_request) Successful in 1m55s

Details

CI / Frontend (pull_request) Successful in 6m34s

Details

CI / Backend (pull_request) Successful in 7m52s

Details

CI / Coverage Results (pull_request) Successful in 26s

Details

CI / Playwright E2E (pull_request) Successful in 8m46s

Details

CI / Build (pull_request) Successful in 2m51s

Details

CI / Semantic Tag (pull_request) Successful in 5s

Details

13fbd70778

forgejo-actions commented

2026-07-19 19:05:41 +02:00

Coverage ratchet: ✅ pass

Suite	Baseline	This PR	Δ
frontend	66.04%	66.06%	+0.02	✅
go	77.50%	77.50%	+0.00	✅

Tolerance: -0.1%. Baseline stored on gh-pages.

### Coverage ratchet: ✅ pass | Suite | Baseline | This PR | Δ | | |---|---|---|---|---| | frontend | 66.04% | 66.06% | +0.02 | ✅ | | go | 77.50% | 77.50% | +0.00 | ✅ | _Tolerance: -0.1%. Baseline stored on `gh-pages`._