[BUG]: Status.get() returns idle for a session absent from the status map #43093

Activity

1. github-actions

   assigned

   neriousy

   on Aug 17, 2026
2. iceteaSA commented on Aug 22, 2026

   

   iceteaSA

   on Aug 22, 2026

   Author

   More actions

   Additional evidence from a plugin that consumes this API in production, plus a second face of the same bug that makes it worse than it first looks.

   The two status APIs disagree about what absence means

   packages/opencode/src/session/status.ts:

   :30  const get = ... (sessionID) {
   :32    return data.get(sessionID) ?? { type: "idle" as const }   // absence → SYNTHESISED idle
   :33  }
   
   :35  const list = ... () {
   :36    return new Map(yield* InstanceState.get(state))            // absence → stays absent
   :37  }
   
   :39  const set = ... (sessionID, status) {
   :42    if (status.type === "idle") {
   :43      yield* events.publish(Event.Idle, { sessionID })
   :44      data.delete(sessionID)      // idle DELETES the entry
   :45      return
   :46    }
   :47    data.set(sessionID, status)   // only reachable when type !== "idle"
   :48  }

   :47 is the only insertion site and is unreachable for type: "idle". So the map's value domain is exactly busy | retry — {type:"idle"} is structurally unconstructible as a map entry, and GET /session/status (handlers/session.ts:85, Object.fromEntries(statusSvc.list())) can never report an idle session.

   That means the same underlying state has two opposite encodings:

   API	idle session	never-ran session	host restarted
   get()	{type:"idle"}	{type:"idle"}	{type:"idle"}
   list()	absent	absent	absent

   get()'s fail-open is what this issue reports. But a consumer that reads list() while holding get()'s mental model gets the inverse failure — and both are reachable from the same public surface.

   Consumer-side cost, observed

   A plugin gating an automated action on "is this session idle?" implemented the conservative reading — absence means unknown, so don't act — which is the correct fail-safe posture for get()'s semantics. Against list() it silently ate 100% of the signal it was guarding: the gate could never open, because the only representation of idle is the absence being treated as unknown.

   Flight-recorder output shows the stall clearly: continuous {verdict: queue, clause: status-absent} re-evaluations at a 120s cadence against a session that was provably idle the whole time. The feature was structurally dead, not flaky. It took four diagnosis rounds before instrumentation named the cause, because every individual component behaved exactly as documented.

   Why this is worth fixing beyond the restart case

   The restart scenario in the original report is the sharpest symptom, but the root defect is that absence is doing double duty as both "idle" and "unknown", with opposite safety implications, and the two APIs resolve that ambiguity in opposite directions. Any consumer that switches between get() and list() — or reasons about one after reading the other — inherits a bug that no amount of correct local reasoning will catch.

   Suggestions, roughly in order of cost:

   1. Make the encodings agree. Either have list() synthesise idle entries for known sessions, or drop the ?? {type:"idle"} default in get() and return an explicit absent/unknown. The second is more honest but is a breaking change for existing get() callers.
   2. Document the asymmetry on both API surfaces if the behaviour is intentional — specifically that an idle session is represented by absence in list(), and that get()'s idle is indistinguishable from unknown.
   3. Distinguish "not running" from "not known" at the type level, which would let consumers make the safety call explicitly instead of inferring it from a hole in a map.

   Worth noting for anyone building on this: session.idle (published at status.ts:43, before the delete) is a positive edge rather than an inferred absence, so it is the more robust signal for event-driven consumers — with the caveat that it fires on all termination shapes (clean, error, interrupt) and so is a quiesce signal, never a success signal. For anything that must survive a restart, message.data.time.completed is durable where the status map is not.
3. neriousy commented on Oct 19, 2026

   

   neriousy

   on Oct 19, 2026

   Member

   More actions

   The v1 status getter that reported idle for sessions it had no record of no longer exists in v2. The v2 API only lists sessions that are currently running, each finished run adds an idle entry to the session transcript recording whether it succeeded, failed or was interrupted, and runs cut off by a crash or restart are resumed when the server starts again. To get v2: npm i -g @opencode/cli@latest or curl -fsSL https://opencode.ai/v2/install | bash (desktop: update the app). If you still see this on v2, please open a new issue with the details.
4. neriousy

   closed this as not plannedon Oct 19, 2026