🤖 tests: ModelsSection discovery and Bedrock endpoint-pinning tests flake in the merge queue

[ThomasK33]

Summary

Two unit test groups fail intermittently in merge-queue runs of unrelated PRs. This is removing PRs from the merge queue.

1. src/browser/features/Settings/Sections/ModelsSection.discovery.test.tsx: many "ModelsSection asynchronous discovery › …" cases hit the 5 s test timeout.
2. src/node/services/bedrockModelDiscovery.test.ts: "pins native us-east-1 / sigv4 / cn-north-1 / us-gov-west-1 endpoints without SDK file/process/chain/metadata work" fails at expect(files).not.toHaveBeenCalled() (the fs/promises.readFile spy sees 1 call).

Evidence (runs whose tree does not contain the other PRs involved)

• ModelsSection: merge group pr-4459 run 36099072466; merge group pr-4449 run 36099068539.
• Bedrock: merge group pr-4449 run 36097692784.
• Both also failed in the merge groups of 🤖 fix: never take a cross-process lock from a live holder #4461 (runs 36099841169, 36103707323), which only changes crossProcessLock. 🤖 fix: never take a cross-process lock from a live holder #4461 was dequeued three times this way.
• hookService.test.ts "headless compaction shares the plugin policy lifecycle: enabled" failed once (run 36101998436). It passes 27/27 over 5 local runs.

Likely area

Both look like cross-test pollution or load sensitivity under Bun 1.3.5 when the shard is busy. The Bedrock spy is global on fs/promises.readFile, so any concurrent reader in the same process trips it. I have not investigated further.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[linear-code]

MUX-207

[ThomasK33]

More merge-queue flakes seen today, each also failing in runs that do not contain the PR under test:

• taskService.reportDecisionHold.test.ts "the interrupted report path publishes only for the stream's attempt: a row re-admitted during the publication write is left to its writer": merge groups of 🤖 fix: keep a newer composer draft when Stop restores a queued message #4449 (36097692784), 🤖 feat: reawakened sub-agents follow current AI settings #4459 (36097639387), 🤖 fix: decide a workflow plan's stream end before its completion prompt #4460 (36101625094).
• WorkflowService > interrupting a run blocked in a child reservation releases its lease so resume is accepted (Unit): merge groups of 🤖 fix: keep a newer composer draft when Stop restores a queued message #4449 (36099068539), 🤖 feat: reawakened sub-agents follow current AI settings #4459 (36099072466), 🤖 feat: opt new user-created workspaces in to unrelated messaging by default #4440 (36099724716). Possibly related to 🤖 tests: WorkflowRunner attemptDisposition lease-release test is flaky #4435.
• Integration Selective plugin imports › same-SHA local file edits refresh inventory and require explicit reselection failed both attempts: merge group of 🤖 fix: refuse isolation none for multi-project task parents #4447 (36100567123) and the PR run of 🤖 fix: never break the config file lock of a live holder #4464.
• E2E streamingBehavior.spec.ts › stream continues after settings opens failed both attempts in the 🤖 fix: never break the config file lock of a live holder #4464 merge group (36110717672), but passed in that PR's own run.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high

[ThomasK33]

The taskService.reportDecisionHold flake came back on #4512 (run 36123536800, job 108034426984, Unit 1/6). The received row points to a lost update, not a timing-only assertion. It may be a product bug.

The test simulates a second backend: otherBackend.editConfig re-admits the row (taskStatus: running, taskAttemptId: att_…c8) from inside this backend's editWorkspaceEntry spy, and rotated became true. The final row still read taskStatus: "interrupted" and taskAttemptId: att_c21d2289360dafc4 (this backend's attempt A). The rotation was overwritten, so this backend's config write went down with a stale view of the file. That matches the caveat at the top of taskService.staleAttemptEffects.test.ts ("only as strong as cross-process config exclusion (#4415)"), and #4464 changed that lock recently.

I did not fix it in WS4a. It is outside the TaskService harness scope (Config and file-lock exclusion), and the stack only moves this test's wiring to the shared createTaskServiceStack builder, which constructs the same objects. The same failure also shows up in merge groups that don't contain these PRs (see the comment above).

[ThomasK33]

Another unrelated merge-queue flake (2026-09-25): src/node/services/taskService.test.ts › "TaskService > cancelled successor forwards disposable ownership to the next queued follow-up" failed at expect(received).not.toHaveBeenCalled() (taskService.test.ts:30779) in merge-group run https://github.com/coder/xum/actions/runs/36127355861 (Test / Unit (1/6)) for #4535, which only changes two browser layout files. The same shard passed on the PR head, and the test passes locally with --rerun-each=5.