You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "kyle7zhang (via GitHub)" <gi...@apache.org> on 2026/08/26 05:26:36 UTC
[I] bug(runtime): sandbox boundary answers wait on the graph wake lease held by the round awaiting them [maka]
kyle7zhang opened a new issue, #3866:
URL: https://github.com/apache/maka/issues/3866
## Summary
When an agent-graph supervisor round is woken and that round raises a sandbox-boundary prompt, answering the prompt deadlocks. The answer path blocks on the supervisor wake coordinator's session-activity lease, which is held by the very round that is parked waiting for that answer. Because the answer holds Session admission while it blocks, every later operation on that Session queues behind it and the Session becomes unusable.
Reproduced on `main` (`v0.2.0`, `d92d277`).
## Symptom
The Session freezes permanently: the transcript stays on `Loading…`, the boundary prompt never renders again, nothing in that Session responds. Restarting the app clears it. Leaving the prompt unanswered is harmless — the Session simply stays parked and the UI keeps working.
<!-- screenshot: Session stuck on Loading after answering the boundary prompt -->
_Screenshot to be attached._
## Reproduction, and where it goes wrong
| # | What you do / see | What happens internally |
|---|---|---|
| 1 | Send a task that instructs the model to **use the agent graph** and that **requires reading paths outside the workspace** | The first round is user-initiated; it never touches the activity lease. It plans and dispatches operators. |
| 2 | Operators run and return one by one | Each milestone can schedule a supervisor wake. |
| 3 | A supervisor round starts (**"Agent graph reached a supervisor checkpoint"**) and raises «Allow access outside the workspace?» | `#deliverWake` **acquires the activity lease** and awaits the round it started. The round parks on the prompt, so the lease stays held. |
| 4 | **Leave the prompt unanswered.** Let the remaining operators finish | Operators run in their own Sessions and never touch this lease. The parked round still holds it. |
| 5 | Once all operators are done, click **Allow for this task** | `interaction.answer` takes Session admission and completes its first five steps. |
| 6 | *(nothing visibly changes yet)* | ⬅ **The faulty moment.** The final step, `#onSandboxBoundarySettled` → `notifyPermissionResponse` → `#settlePermissionResponse`, calls `activityRegistry.acquire(rootSessionId)`. That lease is held by the parked round from step 3 — the round waiting for this answer. No timeout, no abort path. |
| 7 | Open the child task, then navigate back | This forces the UI to re-subscribe. `subscription.open` queues behind the stuck `interaction.answer`, so `readActiveInteractions` never returns and the interaction queue never hydrates. |
| 8 | The transcript stays on `Loading…`; the prompt never renders again | The Session is unusable until restart. |
Step 6 is worth calling out: **nothing visible happens at the moment the deadlock forms.** The freeze only surfaces at step 7, when the UI next re-subscribes — which is why the existing reports describe it as an intermittent hang with no clear steps.
Two things follow from step 3:
- A prompt raised by the **first** round (step 1) does **not** deadlock — that round holds no lease.
- Whether the operators have finished is irrelevant; they never touch this lease. What matters is only whether a wake-started round is parked when the prompt is answered.
The two paths acquire the two mechanisms in opposite order: the wake path takes the activity lease and then repeatedly takes admission for its work, while the answer path takes admission and then wants the activity lease.
Note what step 6 is trying to do: check whether the round waiting on the permission is still alive, so a lost waiter can be retried (`permission_waiter_lost`). A live waiter is precisely one holding the lease — so the check can only ever observe the "waiter is gone" case. The lease also looks redundant there: `completeAgentGraphSupervisorWakeAttempt` already performs an attempt-scoped compare-and-set inside a DB transaction, and `#scheduleRecoveredWake` — the one action that starts a new round — runs outside the lease.
## Proposed fix
1. **Do not take the session activity lease in `#settlePermissionResponse`.** Rely on the existing transactional, attempt-scoped compare-and-set in the wake store, and treat "attempt is no longer current" as a benign outcome. This removes the inverted edge.
2. **Fire the graph-wake notification without awaiting it** from the answer path, so Session admission is never held across a call into another subsystem. This does not fix the deadlock; it caps the blast radius at "the wake is delayed" rather than "the Session is dead".
3. **Add re-entrancy detection to `SessionActivityRegistry`**, mirroring the guard `SessionAdmissionGate` already has, so a future caller on this path fails loudly during development. Separate change — hardening, not a fix.
Adding a timeout to `acquire` is deliberately not proposed: the cycle would remain, and a timeout would convert a deterministic deadlock into nondeterministic state.
## References
- #1114 — introduced `SessionActivityRegistry` for a caller that runs *between* turns, where "wait until the Session is idle" holds.
- #1935 — hosted sandbox-boundary interactions and wired the settle path, whose only call moment is *mid-round*, inverting that precondition.
- #3312, #3328 — both reports show a pending `request_sandbox_boundary` at the time of the freeze; likely the same underlying issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] bug(runtime): sandbox boundary answers wait on the graph wake lease held by the round awaiting them [maka]
Posted by "Flandern1211 (via GitHub)" <gi...@apache.org>.
Flandern1211 commented on issue #3866:
URL: https://github.com/apache/maka/issues/3866#issuecomment-5435193209
I'd like to work on this.
I reproduced the admission/activity wait cycle with a deterministic regression test. The smallest safe fix appears to be the second boundary suggested in the report: do not await graph-wake reconciliation from the sandbox-boundary answer path.
`notifySandboxBoundaryGraphWake()` currently runs while `interaction.answer` owns Session admission. Awaiting `notifyPermissionResponse()` extends that admission across reconciliation, which may wait for the activity lease held by the wake Turn that is waiting for this answer.
My local fix starts that reconciliation asynchronously and consumes its rejection. The wake coordinator keeps its existing activity-lease, idle-wait, error-reporting, and attempt-CAS behavior. This avoids both the deadlock and the separate risk of marking a still-running attempt retryable.
I added a regression test whose wake notification remains pending while the boundary-answer bridge must return. It fails on current `main` with `graph wake blocked the interaction answer` and passes after the change.
Local verification:
- `npm --workspace @maka/runtime-host run build`
- `npm --workspace @maka/runtime run build`
- `node --test packages/runtime-host/dist/__tests__/sandbox-boundary-graph-wake.test.js` — 4/4 passed
- `node --test packages/runtime/dist/__tests__/agent-graph-supervisor-wake.test.js` — 20/20 passed
- Biome check and `git diff --check` passed
I have not opened a PR. I will wait for maintainer feedback on this boundary before doing so.
Investigated and drafted with OpenAI Codex; human-reviewed before posting.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] bug(runtime): sandbox boundary answers wait on the graph wake lease held by the round awaiting them [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han closed issue #3866: bug(runtime): sandbox boundary answers wait on the graph wake lease held by the round awaiting them
URL: https://github.com/apache/maka/issues/3866
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] bug(runtime): sandbox boundary answers wait on the graph wake lease held by the round awaiting them [maka]
Posted by "Flandern1211 (via GitHub)" <gi...@apache.org>.
Flandern1211 commented on issue #3866:
URL: https://github.com/apache/maka/issues/3866#issuecomment-5476015925
The issue is now classified as a Bug, and I have a tested local fix.
Could a maintainer confirm that making notifySandboxBoundaryGraphWake fire-and-forget is the preferred direction? This keeps the wake coordinator's existing activity-lease and CAS semantics while preventing interaction.answer from waiting on the parked wake.
Once confirmed, I will rebase onto the latest main, run the required historical PR review, and open a focused PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] bug(runtime): sandbox boundary answers wait on the graph wake lease held by the round awaiting them [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on issue #3866:
URL: https://github.com/apache/maka/issues/3866#issuecomment-5717624383
Fixed by #4626 (`a4b17ad14`), which took the boundary proposed in this thread: the sandbox-boundary answer no longer awaits graph-wake reconciliation. `packages/runtime-host/src/server/interaction-coordinator.ts` now detaches that notification from Session admission and names this issue at the call site.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org