Sign up
View stargazersSign up

[Bug]: Auto-settle on PR merge settles the thread before the agent hears that the PR merged#29896

opened9d agobyDdominic-r

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Turn on Settle on merge.
  2. Have an agent open a PR in a repository that uses GitHub's merge queue, add it to the queue and call watch_pull_request.
  3. The agent gets the "All N required checks passed" wake and ends its turn with work planned for after the merge, for example "I'll open the next PR in the series once this one merges".
  4. The queue merges the PR.

Expected behavior

The agent gets a turn that tells it the PR merged, and the thread settles only after that turn ends with nothing left pending.

Actual behavior

As soon as the PR sync sees merged, the thread is auto-settled and its provider session is detached. In one event log the settle came 14 ms after the sync event that saw the merge. The agent never runs again, and the work it planned after the merge is not done until someone unsettles the thread and prompts it.

Impact

Major degradation or frequent failure

Version or commit

0.1.7-nightly.20261101.4048 (server); main at d8a829e5

Environment

Linux x86_64, T3 Code server running as a service, Claude provider (claude-opus-5-5)

Logs or stack traces

shell
123:42:40 PR watch wake "All 5 checks passed"; agent replies in 1.5 s and ends its turn
223:42:52 PR merged by the merge queue
323:43:46 PR sync sees merged; watch ends without a wake
423:43:46 auto-settle 14 ms later; provider session detached

In the same install, six threads were unsettled by hand one evening. All six had been auto-settled 35 to 78 minutes earlier when their PR merged, and four still had work left: another PR to ship, a second PR half done, or a test run still going.

Workaround

Turn off Settle on merge.

Related: #25160 is the missing merge wake. This issue is the settle side, which settles before that wake could be delivered. #26097 and #27052 are other settle-on-merge problems with different causes. #29854 fixes this together with #25160.

Written by Claude Opus 5.5 in Claude Code, run from T3 Code.

JJulius Marminge5h ago

I tried to reproduce this on the current build and could not.

Not reproduced in a running app; this was code reading plus a unit test on origin/main 62dc589d6d. A live run needs a GitHub repo with a merge queue and a real agent turn, which I did not set up. The failing test is on branch factory/repro-29896 (56bb7b12df). It adds a case to packages/shared/src/orchestrationV2PendingBackgroundWork.test.ts: a completed run with a watched PR link whose snapshot state is 'merged'. derivePendingBackgroundWork returns [] on main, where the test expects an awaited 'pull-request-watch' task that holds settlement. Command: cd packages/shared && vp test run src/orchestrationV2PendingBackgroundWork.test.ts, which gives 1 failed and 20 passed. In code, PullRequestWatchReactor ends a merged PR's watch through record(target, null) and ended(target, 'merged') with no wake, pullRequestWatchTasks drops links with snapshot.state === 'merged', and ThreadSettlementService then finds nothing holding the thread and dispatches thread.auto-settle as soon as a sync stores the merged snapshot.

Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.