Repository navigation
feat: question escalation — a subsession's question should be answerable by its parent session, passing up the stack if unanswered #1884
Description
Request (Drew, 2026-11-06)
When a subsession calls the question tool, the parent session — the AI orchestrating it — should be able to answer it. If the parent can't or doesn't answer, the question passes up the stack: grandparent, …, up to the root session / attached client. The parent AI is the natural answerer in detached trees; today the form waits only for an external UI/API actor while the whole foreground chain stalls silently (see the very-high-priority stall bug filed alongside this, and #1881 Q6).
Workshop evidence
Evidence: the 2026-11-06 subsession workshop test, filed as #1881 (production server, 8 test sessions, plan pools only; every behavior claim production-measured and re-verified against the session store + route_attempt).
- The form lives on the child (
GET /api/session/<child>/form→frm_…, fields keyedq0…); an externalPOST …/form/<id>/replywith{"answer": {"q0": "Blue"}}returned 204 and unblocked the entire tree instantly. The reply path works — it is just not connected to the session tree.
Design questions to explore
- Order: parent first, then up the ancestry to root, then the attached client/UI? Or client first when one is attached?
- Timeouts per level: how long does each level get before escalation? What happens when the root also times out — handleable cancellation for the child (never a silent stall, never a re-ask loop).
- Payload: reuse the existing form answer shape (
answerkeyed by field key) end-to-end so escalation and the external form API are the same mechanism, not two. - Delivery into the parent: synthetic turn (like background-completion delivery, which the workshop proved works unprompted) vs a tool result on the blocked
subagentcall vs both. - Who may answer: only the direct parent, or any ancestor? What if the parent is itself blocked foreground-waiting on this child (the normal case) — the escalation must still reach it, since answering is what unblocks it.
- Interaction with a future API launch mode that disables
questionentirely (filed separately): disabled mode should short-circuit before any escalation.
Acceptance sketch
- Child asks → parent receives the question in-session and answers → child's
questioncall completes with the parent's answer; no external actor involved. - Parent declines/ignores past its timeout → question surfaces to the grandparent; at root timeout the child gets a visible cancellation it can handle.
- The external form API path keeps working unchanged for attached clients.
Acceptance criteria
- When a subsession calls
question, its parent session can answer it; unanswered questions pass up the ancestor chain to the root session / attached client. - A foreground chain no longer stalls silently while a form waits only on an external UI/API actor — the waiting state is visible to the parent.
- Timeout/fallback behavior (nobody answers) is defined and does not re-ask in a loop.
Activity
dezren39 commentedon Nov 6, 2026
Intake review
Requested by Drew 2026-11-06 (per the issue body). Part of the workshop cluster from opencode issue #1881 (Q6 evidence: form lives on the child,
GET /api/session/<child>/form). Related: issue #1883 (stall bug), issue #1885 (disable-in-detached-mode alternative — the two are complementary: escalation for interactive trees, disable for detached). Effort l: touches form routing across the session tree. Suggested approach: deliver the form as a synthetic turn to the parent first, with pass-up on decline/timeout.— fleet monitor intake (Duty 2), 2026-11-06 run. Acceptance criteria appended to the issue body; labels normalized.
dezren39 commentedon Nov 7, 2026
Feeder triage — gap confirmed on current main
Agent: issue sweep (issue-sweep-rotating, Make feeder)
Checked: 2026-11-07T01:35Z, fresh
ghcalls verified twice. Repo main2d11e0f649436d6c4d20a64ce13fd7e0501bdd96(verified x3); this issue OPEN with noqueue/*,work/*,user/*or safety labels — its only prior comment is the fleet-monitor intake note (2026-11-06T20:27Z). No live queue task indicated; queue backend is in the PostgREST outage (developing-today/code#6619), so dedupe was on gh labels/comments.What I checked (reads only,
gh apiraw — no builds/tests):packages/core/src/tool/plugin/question.ts:74-88— the question tool callsforms.askwithsessionID: context.sessionIDonly (the calling child session).packages/core/src/form.ts— grep forparentreturns no matches on current main:Form.createstores only the child's sessionID;Form.askreturnsDeferred.await(entry.deferred)with no timeout race; the pending-state TTL isDuration.infinity. Nothing delivers, surfaces, or escalates a pending form to any ancestor.POST …/form/<id>/replyreturned 204 and unblocked the whole tree instantly — the reply path works; it is just not connected to the session tree.Done looks like: a subsession question is delivered to its parent in answerable form (existing answer shape, keyed by field key); unanswered questions pass up the ancestry to root/client with per-level timeouts; a root timeout resolves the child call with a visible, handleable result — never a silent stall, never a re-ask loop. Regression tests name their oracle (session-store state + form endpoints before/after).
Scope: #1883 is the stall-bug minimum (already fed); #1885 is the detached-mode disable (picked up by the fleet feature wave, 2026-11-07T01:13Z) — this packet is the escalation feature only.
dezren39 commentedon Nov 7, 2026
🤖 Agent note · triage packet prepared, enqueue outboxed
repo-task/v1triage packet (kindtriage, priority 70, deduperepo-health:v1:triage:developing-today/opencode:issue:1884) into queuerepo-health-opencode-pilot. Packet:hidden_files/packet-opencode-1884.json.queue/queuedlabel is applied with this note.dezren39 commentedon Nov 7, 2026
Picked up by
repo-worker-opencode-a— working this now. (Fleet queue fallback mode: the queue backend is down, so this issue's comments carry the claim. The claim stays live whilerepo-worker-opencode-aposts progress markers; after 30 minutes of silence any other worker may pick this up.)8 remaining items
dezren39 commentedon Nov 7, 2026
🤖 Agent note · queued
dezren39 commentedon Nov 8, 2026
🤖 Agent note · picked up
ses_e5e42778335ffev6v7y7eSxQDx; queue task11017repo-health-opencode-pilot, lane3fe37e8a-c61b-419c-9e97-769ecd264d5dquestionshould be answerable by its parent session, passing up the stack if unanswered #1884 against current GitHub state.kind/design, and no active matching PR was found.questionshould be answerable by its parent session, passing up the stack if unanswered #1884 · prior triage feat: question escalation — a subsession'squestionshould be answerable by its parent session, passing up the stack if unanswered #1884 (comment)dezren39 commentedon Nov 8, 2026
🤖 Agent note · done
ses_e5e42778335ffev6v7y7eSxQDx; queue task11017repo-health-opencode-pilot, lane3fe37e8a-c61b-419c-9e97-769ecd264d5d14135for the design work.questionshould be answerable by its parent session, passing up the stack if unanswered #1884 · feat: question escalation — a subsession'squestionshould be answerable by its parent session, passing up the stack if unanswered #1884 (comment)developing-today commentedon Nov 9, 2026
🤖 Agent note · design verified, parked for a dedicated implementation session — queue task 14135
questioncall stalls child AND foreground parent silently — no notification, and retry machinery re-asks the identical question #1883 (PR fix(core): bound and dedupe question-tool form asks #2188, this shift) gives every question ask a 10-minute bound resolving cancelled-with-message and identical-pending dedupe, so the root-timeout acceptance bullet (visible handleable result, never a silent stall, never a re-ask loop) already holds at the child level while this feature is pending.questioncall stalls child AND foreground parent silently — no notification, and retry machinery re-asks the identical question #1883 bound — no Form-layer escalation state machine unless the implementing session records why the endpoint widening is insufficient; (4) regression tests at the server layer (session-instances / form handler tests) with the session-store + form-endpoint oracle the acceptance names, plus the existing core form/question suites.questioncall stalls child AND foreground parent silently — no notification, and retry machinery re-asks the identical question #1883 is merged, so step (1) can start immediately.dezren39 commentedon Nov 10, 2026
🤖 Agent note · implemented, parked on PR merge — queue task 14135
requireOwnedForminpackages/server/src/handlers/session.tswidened from exact-session ownership to ancestry — get/reply/cancel now accept a form owned by the path session or any descendant, resolved by walking the owner's parent chain via the Session service (Form stays tree-agnostic, cycle-guarded); (2)session.form.listadditionally returns pending forms owned by descendants, each carrying its owning sessionID. Per-level pass-up is a client/orchestrator behavior on top of these endpoints plus the [priority: very high] bug: subsessionquestioncall stalls child AND foreground parent silently — no notification, and retry machinery re-asks the identical question #1883 bound (PR fix(core): bound and dedupe question-tool form asks #2188), so no Form-layer escalation state machine was added. Unrelated sessions and descendants of the owner still get 404; theglobalpseudo-session is untouched.packages/server/test/session-form-escalation.test.ts(root/child/grandchild/unrelated; ancestor list/get/reply/cancel + sideways/downward 404s; oracle = form endpoints + owner-visible state) — passes, and fails without the handler change. Also green: server fetch/session-instances/session-create suites, core form suite (27), server typechecktsgo -b.Fixes #1884); the queue task is parked until then.dezren39 commentedon Nov 10, 2026
🤖 Agent note · triaged
task/pr-shepherd· priority/high · effort/s · kind/feature + kind/design (as filed)dezren39 commentedon Nov 10, 2026
🤖 Agent note · parked (PR ready to merge)
questionshould be answerable by its parent session, passing up the stack if unanswered #1884 OPEN, no hard-stop labels.questioncall stalls child AND foreground parent silently — no notification, and retry machinery re-asks the identical question #1883/feat: question escalation — a subsession'squestionshould be answerable by its parent session, passing up the stack if unanswered #1884); this lane verified readiness and did not merge another worker's PR.