Repository navigation
fix(server): wire the real SessionExecution local layer, not the noop stub - #244
Conversation
… stub
The HTTP server's handler layer graph provided SessionV2.defaultLayer,
which internally bakes in SessionExecution.noopLayer as part of its own
Layer.provide chain (packages/core/src/session.ts). That closes over the
session's SessionExecution.Service dependency permanently at the point
defaultLayer itself is constructed. The sibling
`Layer.provide(SessionExecutionLocal.defaultLayer)` in handlers.ts could
never reach past that already-resolved dependency, since Effect's
Layer.provide binds a layer's requirement when the layer is built, not
when it's later merged into an unrelated layer graph.
Practical symptom: POST /session/{id}/prompt admitted durably (200,
admittedSeq set, a durable row written), but session.wake()/resume()
silently no-op'd, so the agent loop never actually ran. Sessions stayed
at cost=0, tokens=0, with no assistant message ever produced, and
POST /session/{id}/wait 503'd with "Session wait is not available yet"
(a separate, still-unimplemented V2 API stub, not the primary blocker).
Fix: compose the session layer here from the raw SessionV2.layer plus
its concrete sub-layers, substituting SessionExecutionLocal.defaultLayer
for the noop. This mirrors the already-correct pattern used by
packages/core/src/public/opencode.ts's SessionsLayer, which never had
this bug because it wires SessionV2.layer (not defaultLayer) with the
local executor directly.
Not run through bun install/typecheck locally — both the dev host that
surfaced this bug and this workstation are disk-constrained (<2GB free).
Relying on CI (github-hosted runners) to validate the build.
|
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 2 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
The following comment was made by an LLM, it may be inaccurate: |
|
CI note: `unit (linux)` shows 5 failing tests (DatabaseMigration > declared schema has no ungenerated migrations; public native OpenCode API > rejects missing/Location-disabled models; LocationServiceMap > isolates location state / installs public plugins). Confirmed these are pre-existing and unrelated to this change — the same 5 tests, by exact name, fail on a |
Summary
opencode serveHTTP API silently never executing admitted prompts:POST /session/{id}/promptreturns 200 with anadmittedSeq, but the agent loop never runs (cost/tokens stay 0, no assistant message is ever produced).packages/server/src/handlers.tsprovidedSessionV2.defaultLayer, which bakesSessionExecution.noopLayerinto its own internalLayer.providechain (packages/core/src/session.ts). That permanently closes the session'sSessionExecution.Servicedependency over the noop at the pointdefaultLayeris built. The siblingLayer.provide(SessionExecutionLocal.defaultLayer)right below it inhandlers.tscan never reach past that already-resolved dependency — Effect'sLayer.providebinds a requirement when the layer itself is constructed, not when it's later merged into a different layer graph.SessionV2.layerplus its concrete sub-layers, substitutingSessionExecutionLocal.defaultLayerfor the noop — mirroring the already-correct pattern inpackages/core/src/public/opencode.ts'sSessionsLayer, which never had this bug for the same reason (it wiresSessionV2.layer, notdefaultLayer).latest, 1.17.17, anddevHEAD) — not something annpm i @vibetechnologies/opencode@latest+ restart fixes.POST /session/{id}/waitstill 503s ("Session wait is not available yet") — that's a separate, genuinely-unimplemented V2 API stub (packages/core/src/session.ts'swait:handler unconditionally throwsOperationUnavailableError), not the thing blocking execution. Clients should pollGET /session/{id}/messageinstead until that's implemented.Test plan
bun installlocally, both machines I tested from were disk-constrained under 2GB free)npm i -g @vibetechnologies/opencode@latest && systemctl --user restart opencode-serve.serviceon a server host, then create a session,POST /session/{id}/prompt, and pollGET /session/{id}/messageuntil a real assistant message appears (previously stuck atcost=0, empty messages, forever)🤖 Generated with Claude Code