diff --git a/docs/outstanding-issues-inbox/0cf72f07-7f15-4138-81bc-4f425182f0de.json b/docs/outstanding-issues-inbox/0cf72f07-7f15-4138-81bc-4f425182f0de.json new file mode 100644 index 0000000000..4515fe2e8b --- /dev/null +++ b/docs/outstanding-issues-inbox/0cf72f07-7f15-4138-81bc-4f425182f0de.json @@ -0,0 +1,10 @@ +{ + "version": 2, + "id": "0cf72f07-7f15-4138-81bc-4f425182f0de", + "createdOn": "2026-08-21", + "action": "cancel", + "payload": { + "requestId": "67bf71cf-25cb-40d9-a8a2-bbf993bf6b29", + "reason": "Superseded: its diagnosis was partly wrong. It reasoned that failures 1 and 2 were deterministic state assertions and therefore real Windows-only defects rather than load noise. Failure 1 turned out to be a timeout — the test's assertions are fixed but its runtime is not, because it spawns Git Bash twice. Replaced by a single corrected record carrying the resolved status of all five." + } +} diff --git a/docs/outstanding-issues-inbox/4fede43d-fb12-4d85-ba7d-856c46b183f2.json b/docs/outstanding-issues-inbox/4fede43d-fb12-4d85-ba7d-856c46b183f2.json new file mode 100644 index 0000000000..359c422cee --- /dev/null +++ b/docs/outstanding-issues-inbox/4fede43d-fb12-4d85-ba7d-856c46b183f2.json @@ -0,0 +1,12 @@ +{ + "version": 2, + "id": "4fede43d-fb12-4d85-ba7d-856c46b183f2", + "createdOn": "2026-08-21", + "action": "update", + "payload": { + "id": "#6GW95D", + "detail": "UPDATE 2026-08-21 (later the same day): the scope is wider than .claude/worktrees, and the previous update's 69 is itself a floor. An accidental `npx vitest run` issued from C:/Users/joshs instead of the repo root enumerated 253 copies of just TWO test files across the home directory, i.e. 253 separate checkouts of this repository, spread over at least six distinct roots: .codex/worktrees, .gemini/antigravity/worktrees, .copilot/repos/copilot-worktrees, .local/share/opencode/worktree, Documents/Codex///work, and an AppData/Local/pnpm store projects directory (which also contained its own .worktrees). Temp copies under AppData/Local/Temp/guard-push-format-* were still present too. So every AI tool in the fleet keeps its own worktree root and none of them is covered by a sweep scoped to .claude/worktrees. Most had no node_modules (the run failed them with 'Cannot find package'), so raw disk is likely below 253 x 0.89 GB, but the count is the point: any recursive tool run from the home directory now walks all of them. Re-scope this row from 'nine landed worktrees' to a fleet-wide inventory across all six roots before pruning, and keep the #XCAX01 safety preconditions — the 2026-08-21 data-loss incident is why this is not a one-line delete. PRIOR RECORD: UPDATE 2026-08-21 (measured on this machine): the figure recorded here is badly understated and moving the wrong way. git worktree list reported 69 registered worktrees under .claude/worktrees, not nine. At the ~0.89 GB / 51,735-file node_modules per worktree measured in #6SMMB4, even partial installs put this well beyond the 4.5 GB recorded, on a Dev Drive noted as 51% full. SAFETY, learned the hard way on 2026-08-21: a sweep removed an in-use worktree during this very session and destroyed its uncommitted work - see the separate row filed for that. Re-measure actual on-disk size, then prune, but confirm each worktree is landed, holds no uncommitted or unpushed work, AND is not currently checked out by a live agent session before removing it.", + "source": "Accidental home-directory vitest run, 2026-08-21: 253 test-file copies across six worktree roots", + "baseRowFingerprint": "2edd7af71e7e182cf74874a1de2ebb134df9043b945ad47319f7aacbc0fdca2c" + } +} diff --git a/docs/outstanding-issues-inbox/84f3e5c9-2fdb-43bd-80ca-a58bc10f6ec5.json b/docs/outstanding-issues-inbox/84f3e5c9-2fdb-43bd-80ca-a58bc10f6ec5.json new file mode 100644 index 0000000000..f1579cec14 --- /dev/null +++ b/docs/outstanding-issues-inbox/84f3e5c9-2fdb-43bd-80ca-a58bc10f6ec5.json @@ -0,0 +1,14 @@ +{ + "version": 2, + "id": "84f3e5c9-2fdb-43bd-80ca-a58bc10f6ec5", + "createdOn": "2026-08-21", + "action": "add", + "payload": { + "pri": "P2", + "type": "issue", + "summary": "Windows-only test-budget failures: 3 tests fixed (2 of the original 5, plus 1 newly found in the same file), 2 unreproducible, 1 (hosted-migration-role-guard) still unexplained", + "detail": "Supersedes cancelled request 67bf71cf-25cb-40d9-a8a2-bbf993bf6b29, whose diagnosis was partly wrong. ORIGINAL REPORT: a full npm run test on a clean Windows workstation (D:\\Repos\\Database, main at cdfcbaccd, empty tree) exited 1 with 4 files / 5 tests failed, 680 files / 7423 passed, 601.68s. CORRECTED FINDING: main was never broken. A full GATE_RECEIPTS=off npm run test on Linux at the content-identical HEAD is green (696 files, 7770 passed, 4 skipped, exit 0, 196s), and git diff cdfcbaccd..HEAD shows none of the four test files nor their subjects changed. THE ROOT CAUSE FOR THE TWO NOW FIXED IS A TIME BUDGET, NOT A DEFECT IN BEHAVIOUR. (1) codex-cloud-setup 'writes managed shell policy behaviorally and preserves unrelated Codex config' measured 24.96s on that workstation running its file ALONE, against the 30s testTimeout in vitest.config.mts - 83% of budget with nothing competing; a full run puts maxWorkers:4 on the machine and it tips over. It spawns bash scripts/setup-codex-cloud.sh twice, cheap on Linux and expensive on Windows where every spawn goes through Git Bash. Its immediate sibling already carried an explicit 120_000 budget for the same reason (measured 112.9s); this one had been missed. FIXED in PR #2255 by giving it the same budget. (2) http-readiness 'honours the overall deadline when every response remains open' and its neighbour 'destroys stalled requests and resumes polling' both work to millisecond budgets (requestTimeoutMs 40, timeoutMs 180/1000) that Windows cannot hold. The neighbour fails IN ISOLATION ON AN IDLE MACHINE ('expected 4 to be 3'), which is stronger than a load flake: the 40ms request budget bounds not only the two deliberately-stalled responses but also the healthy third one, so a merely-late good response is destroyed as though stalled and the loop polls a fourth time. FIXED in PR #2256 (requestTimeoutMs 40->250 with the deadline 1s->5s; the other case's deadline 180ms->600ms), with a negative proof that breaking the stall-destroy path still fails both. (3) The two document-viewer page-virtualization cases PASS on re-run on that workstation (whole file 3566ms). PR #2252 made their shared failure point legible: flushIdle() could only report 'expected 0 to be greater than 0', which reads as a slow machine; it now names the canvas-budget cause and prints slot/rendered/observer counts. STILL OPEN AND THE REASON THIS ROW EXISTS: hosted-migration-role-guard 'accepts the current repository state' passed on re-run at 1550ms, nowhere near its 30s budget, so the timeout explanation that resolved the other two does NOT fit it and nothing has been changed for it. Its original cause is unexplained. Leading hypothesis, untested: validateRepository() calls repositoryEntries(), which runs git ls-files --cached --others --exclude-standard, so it grades UNTRACKED non-ignored files too - any stray file under scripts/, supabase/migrations/, .github/workflows/ or the guarded exact paths whose name or content matches the reserved role turns it red while git status still looks clean enough to call the tree empty, as would a nested git worktree directory (readFileSync on a directory entry throws EISDIR). It also SHA-256s the on-disk bytes of the pinned immutable migration, so CRLF would break it, though .gitattributes '* text=auto eol=lf' should prevent that and the bytes hash correctly on Linux. NEXT: if it recurs, capture git status --porcelain --untracked-files=all and git ls-files --others --exclude-standard at the moment of failure - the assertion alone will not identify which entry did it. FLAKE POLICY DOES NOT APPLY TO ANY OF THESE: tests/flake-ledger.json is explicitly Playwright-only (exact spec+title, @quarantine tag); all five are Vitest and none are eligible for quarantine. Also note the previously known local-Windows failures (tests/session-start-hook.test.ts, worker-observability) PASSED in the reported run, so any note calling those the known environmental set is stale. STANDING LESSON: on this workstation, a test's assertions being deterministic does NOT make its runtime deterministic. Subprocess-spawning and wall-clock-bounded tests need budgets sized for Windows, and 83%-of-budget in isolation is a latent failure, not a pass.", + "source": "PRs #2252, #2255, #2256 (2026-08-21); Windows workstation runs at cdfcbaccd and after", + "issueUlid": "01M0JZPXQNBJ80DBB4TRD9RS19" + } +} diff --git a/docs/outstanding-issues-inbox/e271b2da-5c74-4d84-96f3-bc96821d2d94.json b/docs/outstanding-issues-inbox/e271b2da-5c74-4d84-96f3-bc96821d2d94.json new file mode 100644 index 0000000000..755803ef07 --- /dev/null +++ b/docs/outstanding-issues-inbox/e271b2da-5c74-4d84-96f3-bc96821d2d94.json @@ -0,0 +1,12 @@ +{ + "version": 2, + "id": "e271b2da-5c74-4d84-96f3-bc96821d2d94", + "createdOn": "2026-08-21", + "action": "update", + "payload": { + "id": "#CCZ4HB", + "detail": "UPDATE 2026-08-21 (second session, three PRs later): STILL HAPPENING, and now measured on consecutive PRs rather than one. CodeRabbit skipped review on PR #2252, #2255 and #2256 — every PR opened in that session — reporting: 'Your 88 included PR review attempts over the past 7 days set your current allowance at 1 review per hour' and 'Your organization has reached its usage spending cap.' Countdown observed shrinking across the session (48 minutes -> 32 -> 27), i.e. the hourly allowance was being consumed as fast as it refilled. Two refinements to the row below. (1) The 2026-08-18 reading was 101 reviews/7 days; this one is 88 attempts/7 days, so the trailing window is falling but the spending cap is the binding constraint now, not the rate limit — raising the cap is therefore the lever, and it is an account/billing decision the repo cannot gate its way out of. (2) Draft PRs are skipped outright ('Review skipped. Draft detected'), so the repo's own default of opening PRs as drafts guarantees no bot review until someone undrafts — and undrafting mid-CI also cancels the in-flight run and reds the required aggregate (observed on #2255 and #2256). That interaction is worth stating in AGENTS.md: the draft default, the review-bot budget, and the cancel-in-progress churn are the same problem seen from three sides. Next unchanged: decide between a churn gate, raising the cap, or accepting unreviewed merges deliberately. PRIOR RECORD: CodeRabbit on PR #2113: '101 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour. Your organization has reached its usage spending cap.' The Codex connector reported its own usage limit on the same PR. Net effect: #2113 received ZERO automated review, and so will subsequent PRs until the cap resets or credits are added. AGENTS.md 'PR bundling' already measured the CI half of this cost on 2026-07-30 (437 PR-triggered runs over ~3 days, ~40% cancelled mid-run, ~12 Production-UI-hours burned on runs that never completed). This is the second bill for the same behaviour and the more dangerous one, because CI waste is money while missing review is undetected defects — and the PRs most likely to need review are the ones landing during a churn spike. The bundling rule exists as prose in AGENTS.md and is evidently not binding; the newtask skill also asks the question in prose. Decide whether it gets a gate. Note the repo has already learned this lesson once in a different area: .claude/hooks/pr-handoff-stop.sh states in its own header that 'prose rules in AGENTS.md have not held, a denied tool call does.' Next: decide between (a) a push/PR-creation gate that refuses a new branch when an open PR of the same scope exists, (b) raising the bot spending cap, or (c) accepting unreviewed merges deliberately rather than by accident. Stop rule: do not weaken any required check to compensate for missing bot review.", + "source": "CodeRabbit comments on PRs #2252, #2255, #2256 (2026-08-21); prior evidence PR #2113 (2026-08-18)", + "baseRowFingerprint": "bfc39e062f42860bc22db9ef0a32c955317e8d8dd73f75d35a3f8de95933eb0e" + } +} diff --git a/tests/http-readiness.test.ts b/tests/http-readiness.test.ts index f58ac55f2c..b6280c4390 100644 --- a/tests/http-readiness.test.ts +++ b/tests/http-readiness.test.ts @@ -53,8 +53,16 @@ describe("bounded HTTP readiness", () => { url, isReady: ({ statusCode, body }: { statusCode?: number; body: string }) => statusCode === 200 && body === "ready", - timeoutMs: 1_000, - requestTimeoutMs: 40, + // The first two responses never end, so they consume the whole request + // budget however large it is — the stall path is exercised either way. + // What the budget must NOT do is cut off the THIRD response, which is + // healthy: that misreads a good response as stalled and polls a fourth + // time, failing this test's `toBe(3)`. At 40ms it did exactly that on a + // Windows workstation, reproducibly, on an idle machine running this + // file alone. Raised to 250ms, with the overall deadline lifted to keep + // room for two full stalls plus the real attempt. + timeoutMs: 5_000, + requestTimeoutMs: 250, pollIntervalMs: 5, }), ).resolves.toBeUndefined(); @@ -76,7 +84,14 @@ describe("bounded HTTP readiness", () => { waitForHttpReadiness({ url, isReady: () => false, - timeoutMs: 180, + // Every response stalls here, so each attempt costs the full 40ms and + // the deadline decides how many fit. 180ms left room for four, which is + // thin: one late timer on a loaded machine yields a single attempt and + // fails `toBeGreaterThan(1)` — the shape reported from a Windows + // workstation. 600ms fits roughly thirteen, so the assertion needs the + // loop to actually poll rather than to win a race. The deadline is + // still honoured and still bounded; both assertions below are unchanged. + timeoutMs: 600, requestTimeoutMs: 40, pollIntervalMs: 5, timeoutErrorMessage: "readiness deadline elapsed",