Observed while verifying grip#776's final comment-only commit. On one run under elevated system load (`uptime` reported load averages 2.85/6.16/6.56 -- other agents' concurrent sessions on the shared machine), this test failed:
```
ℹ app: no CI checks configured for branch 'feat/no-ci', proceeding
⚠ 0 merged, 1 failed:
app: PR #42 - merge reported success but PR is not merged
thread 'test_pr_merge_wait_does_not_block_when_no_checks_are_configured' panicked at tests/test_pr_merge.rs:736:5:
expected --wait to resolve immediately (no checks configured means nothing to poll for), took 14.361463875s instead
```
The `checks_configured` guard itself fired correctly (the "no CI checks configured, proceeding" line printed), but something downstream -- the merge-verification re-fetch (`merge.rs` ~line 707-714, which calls `get_pull_request` again after the merge PUT to confirm `verified_pr.merged`) -- took an unexpectedly long path and the mock's post-merge state wasn't observed as merged.
Reproduced 3x in isolation right after: 1 failure (13.41s), then 2 clean passes (4.57s, 4.06s) with zero code changes between runs -- confirms this is load/timing-sensitive, not deterministic. Full suite (`cargo test --test test_pr_merge`) passed 12/12 cleanly once system load settled.
Didn't root-cause further -- outside grip#776's scope and system was already noisy. Worth a look if it recurs: possible candidates are the wiremock server occasionally serving a stale/default response under scheduling pressure, or a race between the merge PUT and the verification GET that only manifests under delay. Filing so it's tracked rather than silently reproduced by whoever hits it next.
Observed while verifying grip#776's final comment-only commit. On one run under elevated system load (`uptime` reported load averages 2.85/6.16/6.56 -- other agents' concurrent sessions on the shared machine), this test failed:
```
ℹ app: no CI checks configured for branch 'feat/no-ci', proceeding
⚠ 0 merged, 1 failed:
app: PR #42 - merge reported success but PR is not merged
thread 'test_pr_merge_wait_does_not_block_when_no_checks_are_configured' panicked at tests/test_pr_merge.rs:736:5:
expected --wait to resolve immediately (no checks configured means nothing to poll for), took 14.361463875s instead
```
The `checks_configured` guard itself fired correctly (the "no CI checks configured, proceeding" line printed), but something downstream -- the merge-verification re-fetch (`merge.rs` ~line 707-714, which calls `get_pull_request` again after the merge PUT to confirm `verified_pr.merged`) -- took an unexpectedly long path and the mock's post-merge state wasn't observed as merged.
Reproduced 3x in isolation right after: 1 failure (13.41s), then 2 clean passes (4.57s, 4.06s) with zero code changes between runs -- confirms this is load/timing-sensitive, not deterministic. Full suite (`cargo test --test test_pr_merge`) passed 12/12 cleanly once system load settled.
Didn't root-cause further -- outside grip#776's scope and system was already noisy. Worth a look if it recurs: possible candidates are the wiremock server occasionally serving a stale/default response under scheduling pressure, or a race between the merge PUT and the verification GET that only manifests under delay. Filing so it's tracked rather than silently reproduced by whoever hits it next.