Skip to content

fix(core): await child background work before subagent completion - #49305

Open
Ploppy3 wants to merge 4 commits into
anomalyco:v2from
Ploppy3:subagent-quiescence
Open

Ploppy3 wants to merge 4 commits into
anomalyco:v2from
Ploppy3:subagent-quiescence

Conversation

@Ploppy3

@Ploppy3 Ploppy3 commented Sep 16, 2026

Copy link
Copy Markdown

Issue for this PR

Closes #48826

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

A subagent that ends a turn while it still has pending background work (shell or nested subagent with background: true) is reported to its parent as completed at that first idle. The subagent job settled as soon as sessions.resume(child) returned, so the parent received the child's early reply; when the pending work later woke the child and it produced its real result, nothing delivered it.

  • SubagentCompletion.finalText runs the child to quiescence before reading its response: while the child still owns pending background notifications that will wake it, it waits for their delivery and resumes again.
  • New Job.awaitBackground(notificationID) resolves when the notification is admitted (its durable marker clears). Waiting for job settlement alone races that asynchronous delivery.
  • Live subagent jobs and restart recovery share the same body, so recovered jobs behave identically.

How did you verify your code works?

cd packages/core && bun test test/job.test.ts test/tool-subagent.test.ts — the new regression test (waits for pending child background work before notifying the parent) fails when run against the un-fixed source (Expected "running", Received "completed") and passes with the fix.

Reproduced the original failure on v2: the parent was notified with SHELL_STARTED while the child's background shell was still running, and the child's later WOKEN_RESULT_COLLECTED stayed stranded in the child session.

Screenshots / recordings

Not a UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

@github-actions github-actions Bot added needs:compliance This means the issue will auto-close after 2 hours. needs:issue labels Sep 16, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

  1. Open an issue describing the bug/feature (if one doesn't exist)
  2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

@github-actions

Copy link
Copy Markdown
Contributor

Thanks for updating your PR! It now meets our contributing guidelines. 👍

@Ploppy3

Ploppy3 commented Sep 16, 2026

Copy link
Copy Markdown
Author

The description now follows the PR template section for section and the compliance check passes:

  • ### Issue for this PRCloses #48826
  • ### Type of change — bug fix checked
  • ### What does this PR do?
  • ### How did you verify your code works?
  • ### Screenshots / recordings — not a UI change
  • ### Checklist — both items checked

One note for maintainers on the remaining needs:issue label: it can't clear itself for PRs targeting v2. The pull_request_target run uses the workflow copy without the v2 body fallback, so it only reads closingIssuesReferences, and GitHub returns 0 closing references for PRs that don't target the default branch. Other v2 PRs with a Closes reference (e.g. #48928, #49295) carry the same label. The issue link is present in the description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant