ui-react: policy review can miss its post-approval updated-state deadline
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 8/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- bun, docker, playwright, react, typescript
- Domain
- frontend, testing-qa
Research direction
The failing assertion is the post-approval poll for [data-policy-state="updated"] in packages/ui-react/tests/browser/policy-review.layout.tsx, around line 107 on main. Read the thread's controlled reproduction, which uses a CPU-quota gate, before anything else. Done means an explained cause backed by a failing-first receipt at the real boundary, not a longer timeout or a retried run.
Written by the indexing model from the issue text.
Description
Current prerequisite — 2026-10-18
Publication-boundary source review is complete; the original cause remains unresolved. Native investigation is blocked before assertions by the shared Docker API returning HTTP 500 and subsequent calls timing out. The environment operator must restore the shared engine and verify pinned offline container startup/exit, then inspect brain-policy-runtime-fa9214ae-r3 for cleanup before resumption. Retained journal/checkpoint/publication diagnostics support the next bounded experiment. No new runtime pass, repair or candidate qualification is established; existing controlled recurrences and release commitment remain. See the dated runtime-blocked evidence comment.
Diagnostic delivery — 2026-10-16
PR #2005 is merged under Refs as ab0e9fb77a236cefbe5a0b19424836acf9205bde, parent 44a8ab0be7e48a73f61bc794e65ea3f8e84e4289, tree f2878ef7621797e4de23c1e2a493b3fefab6d099. Fetched-main ancestry and the actual squash parent/tree match the conflict-free preview. This supersedes the earlier draft-only handoffs below.
Ready qualification 38878831232, attempt 1 passed all thirteen selected jobs: 3,761 unit cases, 8,808 browser cases with ten reviewed intended exclusions, and 1,099 layout cases, including all eighteen policy-review cases and the original ten-minute endurance/decode guard. Every selected job's actual checkout log was verified as 770c62aee412201aecf90d56071fea4a859bebeb, parents tested base abe5086df48883bc270a36edb127b05519398332 and PR head fb9a3144b7ed05947cf27ad5d01dc0bc4bfe0128, tree b1f51cc76c0eb5c0ad51e9fbbd8d08472065f14a. No reused categories or selected failures/cancellations. Packaging was intentionally unselected for the two-file test/fixture diff. Local preflight and diagnostic mutations are recorded in the PR.
Main advanced during qualification through storage documentation and an isolated cold-capture command readiness correction. The PR records the source relevance assessment. The earlier ready proof retains its actual tested base/tree; it is not relabeled as execution on the later squash. Automatic main-push CI 38882310028 has started; no passing claim is made for that still-running execution.
#1872 and #2004 remain open with milestone 0.44.0. This delivers reliable failure snapshots and bounded native approval/publication traces, not a product repair or an explanation of either historical spontaneous failure. #1858/#1870 remain blocked by #1872. Resume with a natural failing timeline or a newly justified causal experiment; do not repeat unchanged passing controls or infer the historical cause from inserted CPU/SQLite conditions. Original deadlines, security, byte/focus assertions and offline guards remain intact.
Claim 2004-fa9214ae-qualify-20261016-r1 is complete and being released. Existing investigation readiness is retained. No publishing or deployment was performed.
Out of scope
The original initial-receipt readiness failure in #1872, changing policy authority, weakening focus/byte-equality/theme/zoom assertions, increasing deadlines without causal evidence, or retrying the failed file unchanged.
Context
Found while investigating #1872. On main 4e4a663f98054d86f2dc90154b42ffbe8f8b7692 plus a test-only failure-snapshot correction, one complete pinned native policy-review file failed dark 1280 100%: policy diff, focus and approved bytes at the post-approval updated-state poll. Main source: the approval click and poll at packages/ui-react/tests/browser/policy-review.layout.tsx:107, following the unchanged full-diff and focus assertions at :95-106. The diagnostic candidate moves this assertion to line 116, without changing it or the executed successful scene path.
Result: 16 passed / 1 failed across 17 cases, Vitest 32.35 seconds / command 35.892 seconds. Assertion: expected null not to be null, caused by Matcher did not succeed in time, querying [data-policy-state="updated"]. Every initial receipt scene passed, including both previously reported #1872 cells. The new diagnostic snapshot regression and existing refused-transport diagnostic passed. The failure precedes the subsequent write-byte, single-write, journal and next-turn assertions; those are not evidence for this failed cell.
Runtime: Bun 1.4.2, Vitest 4.1.11, React 19.3.0, native Chromium in mcr.microsoft.com/playwright:v1.63.0-noble, uid 1000, serial files, offline network namespace, existing guards and checksum-locked read-only fonts, four CPUs, 8 GiB/no swap. Cgroup peak 1,351,192,576 bytes, zero max/OOM/kill events, no throttled periods; user CPU 15.095796 seconds / system 4.809244 seconds. Unrelated host activity was not controlled. These observations do not identify a resource cause.
The original error has no failure-boundary receipt/approval timeline; the controlled reproduction below now supplies one for its distinct resource condition. It does not establish whether native click delivery, decision dispatch, host publication, completion delivery or React commit caused the deadline miss. No unchanged retry or correction has been attempted. Searches for policy/approval/layout and policy/updated found no matching open investigation; #1749 is journal attribution and #1872 is initial receipt readiness. This finding is standalone by reference to native verification epic #736, whose direct-child inventory is already at its limit.
Scope
The bounded controlled reproduction below establishes sensitivity at the post-approval completion boundary. Continue classifying the historical failure using native activation, decision dispatch/ownership, host publication/journal observation, completion-frame and committed-render evidence before selecting a repair. Preserve the distinction between the imposed resource condition and the unknown original condition.
Acceptance criteria
- Preserve the failed source/runtime identity and original assertions.
- Establish a bounded natural reproduction or a justified controlled experiment; distinguish it from #1872's initial-readiness failure.
- Any repair supplies a named failing-first/mutation receipt at the actual boundary, then passes the unchanged byte/focus/security and complete affected file assertions.
- Complete selected hosted proof on the actual candidate before claiming qualification.
Verification
Run the pinned offline layout project with the complete policy-review file, original cases and deadlines. Record actual checkout, order and resources. Retain the original failed receipt; a focused pass alone does not resolve this failure.
Contract impact
None established. No production or machine-contract change is proposed.
Bounded publication-boundary observation — 2026-10-16
Resumption claim 1872-fa9214ae-resume-20261016-r2 inspected draft #2005 at a34a049b4630e87240354b8573116a3114845fc2, based on 4e4a663f98054d86f2dc90154b42ffbe8f8b7692. No new review or inline findings exist. Current draft CI 38839705290 and contract 38839706193 passed their cheap selected gates; complete ready proof remains intentionally unexecuted. No older run is relabeled as a new candidate receipt.
One bounded temporarily instrumented complete-file execution added browser native-click/send/frame/DOM stages and server incoming-message, outgoing-frame, principal/turn and publication-observe/write stages. The server kept its own independent monotonic clock. Existing assertions, deadlines, original cases, native policy/journal writes, offline guards, pinned fonts and runtime stayed unchanged. Observation and logging can perturb scheduling; this does not qualify the clean committed source.
Result: 17 passed, no skips/errors, exit 0; Vitest 29.99 seconds / command 33.639 seconds. All eight matrix cells dispatched approval 32.1–43.8 ms after click initiation and committed updated DOM 236.5–452.7 ms after dispatch. Publication observation took 212.695–429.029 ms, with synchronous write callbacks 3.939–4.216 ms. Each wrote exactly once and reached the original downstream byte/focus/journal/next-turn assertions. The formerly failed dark/1280/100% cell dispatched in 37.6 ms and updated 452.7 ms later; its publication observation took 429.029 ms. No missing dispatch, publication failure, ownership loss or completion/render failure occurred in this diagnostic control.
Runtime: Bun 1.4.2, Vitest 4.1.11, React 19.3.0, native Chromium in pinned Playwright v1.63.0-noble, ordinary uid 1000, serial files, offline namespace/guards, checksum-locked read-only fonts, four CPUs / 8 GiB / no swap. Final cgroup peak 1,270,407,168 bytes; zero max/OOM/kill events or throttled periods; CPU user 15.066187 seconds / system 4.279933 seconds. Host activity was uncontrolled. These metrics provide no causal load attribution or speedup claim.
The original post-approval failure in #2004 remains unexplained. This observation-only pass is neither an unchanged retry of the failed source nor a repair: its purpose is the previously missing boundary trace. The original failed run remains failed, and no instrumented pass substitutes for complete current-candidate qualification. Temporary tracked edits are restored; raw log, observation patch, resource receipt and eight-cell summary are preserved locally. No new source correction, commit, push, hosted run or merge occurred.
Handoff: keep #2005 draft and #1872 open. Obtain an actual failing post-approval timeline or a newly justified causal experiment for #2004 before choosing a repair or another complete-file run. In parallel, #1872's original missing-proposal-arrival timeline remains a distinct investigation; the snapshot correction does not complete it. The healthy publication trace does not unblock #1858/#1870. Existing milestones/readiness remain, and claim 1872-fa9214ae-resume-20261016-r2 is released. Resume from the preserved branch/evidence without repeating these unchanged passing controls.
2026-10-16 update: recorded the bounded healthy native publication timeline, its instrumentation limits and the unchanged causal gap.
Controlled post-approval reproduction — 2026-10-16
Claim 2004-fa9214ae-20261016-r1 reproduced the exact original named case and assertion on PR #2005 head a34a049b4630e87240354b8573116a3114845fc2 plus temporary observation/resource-gate instrumentation. The clean base remains 4e4a663f98054d86f2dc90154b42ffbe8f8b7692. This is a controlled resource-induced recurrence, not a claim that the original four-CPU failure had this cause.
The container starts with four CPUs and 8 GiB/no swap. After the original scene receipt, full-diff open/Escape/focus and sizing assertions complete, the fixture signals an external gate immediately before the original approval click. The orchestrator changes only that container's CPU quota, reads Docker HostConfig back and releases the gate. The original click, one-second updated-state poll and all subsequent assertions remain unchanged. Browser send/frame/DOM and server principal/turn/publication-observe/write stages are observation-only; logging/gating can perturb scheduling. No fabricated approval result, forced write, generic post-click sleep, timeout increase or original-job retry is used.
| Post-setup CPU quota | Result | Command wall | Native evidence |
|---|---|---|---|
0.25 CPU (cpu.max = 25000 100000) |
Named case passes; 16 intentionally filtered | 6.628 s | Approval sends 70.9 ms after click initiation; updated DOM 313.9 ms after send; host publication observation 291.078 ms; one write; original downstream assertions pass. |
0.05 CPU (cpu.max = 5000 100000) |
Named case fails the original updated-state assertion; 16 intentionally filtered | 16.037 s | Approval sends after 801.6 ms. Native click command settles after 1499.3 ms. The unchanged poll fails 1003.0 ms later with expected null not to be null; frozen DOM still says Writing the policy…. |
Restored 4 CPUs (cpu.max = 400000 100000) |
Named case passes; 16 intentionally filtered | 7.206 s | Approval sends after 26.3 ms; updated DOM 411.0 ms after send; host publication observation 372.639 ms; one write; original downstream assertions pass. |
In the failing arm, browser dispatch and the real server's incoming approval agree on the same session/turn with epoch 0. The browser receives the writing result, but no final updated result is in the frozen failure snapshot. Server publication observation takes 1142.499 ms, including a 5.935 ms synchronous write callback. The later diagnostic fixture sample reports exactly one published write, the original proposed bytes, user policy event and final outgoing result. Thus the controlled deadline miss occurs while the browser awaits completion; it is not missing native activation, failed receipt verification or evidence that no write occurred. Browser/server monotonic clocks remain separate: only intervals within each clock are compared.
The failure arm records 105 throttled periods / 42.382085 aggregate throttled seconds, peak 1,309,208,576 bytes and zero memory max/OOM/kill events. The restored arm has no throttled periods, peak 1,287,630,848 bytes and zero memory events. Runtime remains Bun 1.4.2, Vitest 4.1.11, React 19.3.0, pinned Playwright v1.63.0-noble native Chromium, ordinary uid 1000, offline network namespace/guards, serial browser files and checksum-locked read-only fonts. Host activity was not controlled. These are whole-container metrics, not per-test CPU attribution or a quantitative performance comparison.
This also exercises #2005's snapshot correction at a real failed asynchronous boundary: its browser evidence remains writing while the explicitly later server sample reports completion. Neither observation overwrites the other. The full original failure remains retained; no failed test is rerun unchanged to obtain green. The final passing arm changes the deliberately reduced quota back to four CPUs and is a comparison control, not a repair.
Outcome and remaining work: the bounded reproduction/controlled-experiment prerequisite is now satisfied. Remove needs: repro and make this scoped investigation agent-ready, without inventing a priority or selecting a repair. The historical initiating condition is still unknown: the original run reported no cgroup throttled periods, so this experiment does not attribute it to the imposed quota. Next, determine whether a production or fixture correction is justified using native completion/observation evidence; do not simply raise the deadline. Preserve the exact bytes/security/focus assertions, obtain failing-first/restored proof for any actual correction, and qualify the complete file/current hosted candidate before declaring resolution. #2004 stays open and #2005 stays draft; #1872's initial-arrival investigation remains distinct.
Temporary tracked instrumentation is restored, and the clean published branch remains unchanged. Raw logs, exact observation patch, gate/runner, HostConfig receipts and parsed timeline/summary are retained locally. No product correction, new commit, push, complete-file rerun, hosted proof or merge is claimed. Claim 2004-fa9214ae-20261016-r1 is released at this handoff.
2026-10-16 correction: replaced the missing-reproduction handoff with a bounded controlled recurrence and comparison controls; the original cause and any repair remain unresolved.
Different mechanism: real SQLite writer contention — 2026-10-16
Claim 2004-fa9214ae-storage-20261016-r1 tested draft #2005 head a34a049b4630e87240354b8573116a3114845fc2 plus temporary observation/storage-gate code. Unlike the earlier quota experiment, all arms retain four CPUs (cpu.max=400000 100000) and record zero throttled periods, with zero memory max/OOM/kill events. The original click, one-second updated-state assertion, policy authority and byte/focus/security assertions are unchanged. Runtime remains pinned offline Chromium/Playwright v1.63.0-noble, Bun 1.4.2, Vitest 4.1.11, React 19.3.0, uid 1000, 8 GiB/no swap, serial browser files and checksum-locked read-only fonts.
Source review did not support the initial lingering-overlay hypothesis: Overlay's layout cleanup closes the native modal and its closed render returns null before the queued focus restoration (Overlay, packages/ui-kit/src/chrome/Overlay.tsx). A separate source fact supports a storage-contention experiment: createUiDb configures PRAGMA busy_timeout = 5000 (packages/ui-server/src/db/client.ts:34), while the original browser updated-state poll has a default 1000 ms budget. Policy save updates SQLite before emitting its receipt (packages/ui-server/src/brain/policy-proposal.ts:123-127). No source correction is selected from this review.
Experiment: after original receipt/diff/Escape/focus setup, an external Bun actor opens the disposable fixture database and successfully executes a real BEGIN IMMEDIATE transaction in WAL mode. It changes no data and holds the writer reservation until the controller observes the original browser poll failure. The controller then releases it by ROLLBACK. The actor uses the existing child network preload inside the offline container. This holds a real native database lock; it fabricates no approval response, replaces no SQLite method and adds no generic post-click sleep. Browser and server boundary traces retain independent monotonic clocks.
| Arm | Result | Command / Vitest wall | Evidence |
|---|---|---|---|
| Held writer | Original named updated-state assertion fails | 6.916 / 3.53 s | Approval dispatch after 28.0 ms; poll fails 1005.8 ms after click settles. Browser is still Writing; server receives approval but has not emitted its writing result at the frozen failure boundary. Actor rolls back after 1065.089 ms. |
| No held transaction | Named case passes | 5.694 / 2.79 s | Same actor and setup gate, no BEGIN IMMEDIATE. Approval dispatch after 29.2 ms; original downstream focus/bytes/journal/next-turn assertions pass with one write. |
| Held writer plus post-failure observation | Original failure remains the result | 9.291 / 6.51 s | Dispatch after 15.1 ms; original poll fails after 1005.0 ms. The added observation starts only after the frozen failure snapshot, waits up to three seconds for updated DOM, samples actual state, then always rethrows the original failure. Recovery reports exactly one write, byte equality with the proposed policy, updated DOM and the original user policy event. Actor rolls back after 1042.367 ms. |
All arms select only dark 1280 100%: policy diff, focus and approved bytes; sixteen cases are intentionally filtered. Both held actors exit 0 and retain a rollback receipt whose release reason is the observed original poll failure. The failure sample can precede the actual write: the first held arm's later fixture sample still has zero writes and publication observation just beginning. The additional recovery observation resolves that limited sample; it is not a deadline extension, passing retry or replacement of the failed original assertion. Failing arms do not reach the original post-approval downstream assertions; recovery byte/write/event facts come from the separately labeled observation and parsed native evidence.
Whole-container memory peaks are 1,353,478,144 bytes (held), 1,316,786,176 (comparison) and 1,233,756,160 (held/recovery). Host activity was uncontrolled; these metrics establish no performance improvement. The server's incoming-approval-to-writing-frame gap is 1037.723 ms in the first held arm and 3635.946 ms in the recovery arm. These gaps are not asserted to equal the actor's lock lifetime; scheduling/retry behavior after release is not independently attributed.
Conclusion and limits: a real competing SQLite writer is another sufficient condition for the exact assertion failure at normal CPU quota, distinct from the earlier severe CPU restriction. There is still no evidence that the original failure had a second writer: the browser fixture normally creates its own private database and does not launch the product's cron writer. This controlled actor is an inserted condition, not a diagnosis of historical contention. The snapshot correction correctly preserves the earlier Writing browser state while later completion is observed. No timeout, guard or product behavior was changed.
Temporary tracked probes are restored; the published branch remains clean and unchanged. Logs, writer/gate runner, both temporary patches, actor/rollback/resource receipts and parsed recovery evidence are preserved locally. #2004 remains open and ready for investigation; #2005 remains draft. The requested different reproduction approach is complete, with no selected repair, complete-file qualification, new commit/push, hosted run or merge. Claim 2004-fa9214ae-storage-20261016-r1 is released at this handoff. Resume from the recorded controls; neither sufficient-condition experiment alone justifies changing a production path or extending the original test deadline.
2026-10-16 update: recorded a distinct native writer-contention recurrence and recovery observation, preserving the difference between inserted conditions and the unknown original cause.
Retained post-approval diagnostics and normal-condition investigation — 2026-10-16
PR #2005 now publishes d2adff34a800e68e1e14cffdc141b78c2343232d (parent a34a049b4630e87240354b8573116a3114845fc2, tree 4a1930d91c0473be578ab73e607c406b841f58f2). The user-approved diagnostic extension is retained in the branch: the original updated-state poll now reports a frozen browser snapshot, bounded native approval capture/dispatch evidence, server incoming/outgoing frames including policy state, journal observation/write/settlement and DOM transitions. Later fixture evidence is separately sampled; clocks remain independent. The original assertions, one-second deadline, journal promise and policy/security behavior are preserved. Direct SQLite-statement timing is not instrumented; incoming-approval-to-outgoing-writing spans that preceding path without attributing its duration to a specific query.
A new native case uses the existing dropped-result mode after a real write, verifying one correct write, actual trusted click/dispatch in the frozen trace, journal completion and a deliberately suppressed updated result. Swallowing the updated-state error makes that named test fail on expected undefined to be an instance of Error (exit 1, 6.256 s command / 3.42 s Vitest); the mutation is restored.
Normal-condition full-file result: all 18 cases pass, no skips/errors, exit 0, 32.930 s command / 30.22 s Vitest. No spontaneous recurrence of #2004 occurred. Four CPUs / 8 GiB / no swap, no competing SQLite actor or reduced CPU quota; peak 1,313,906,688 bytes, zero memory max/OOM/kill events and zero throttled periods. Native runtime remains Bun 1.4.2 / Vitest 4.1.11 / React 19.3.0, pinned offline Playwright v1.63.0-noble Chromium, uid 1000, serial files, existing guards and verified read-only fonts. Host activity was uncontrolled, including concurrent ordinary TypeScript verification. Successful runs retain bounded traces only in memory; failure reports emit them.
After that complete-file run, a small metadata/assertion refinement adds explicit outgoing policy state and verifies the frozen rather than live browser trace. The final focused native case passes in 6.050 s command / 3.31 s Vitest, with seventeen intentional name-filter exclusions. The earlier full-file pass retains its source identity; it is not relabeled as a complete execution after that refinement. Final Bun-hosted TypeScript passes; preflight passes all local gates and 54 cases / 181 assertions. This is test/fixture-only work with no changeset or machine-contract change.
Draft CI for the new head passes its cheap metadata/proof selection; full ready-candidate proof is not selected. Main has advanced through shared wire/WS code and other work, so this original-branch run is not evidence for the new main combination. Prior failures and controlled CPU/SQLite recurrences remain preserved and are not called repairs or retry successes.
Handoff: the approved one-run investigation and retained diagnostic extension are complete. #2004 and #1872 remain open because the original initiating condition is unknown; neither dependent PR is unblocked. #2005 remains draft under Refs. Continue from these retained failure diagnostics, assess/integrate relevant main inputs before candidate qualification, and obtain complete selected hosted proof before any merge. No production repair or historical attribution is claimed. Claim 2004-fa9214ae-retained-20261016-r1 is released; the pushed branch is clean and no diagnostic container remains running.
2026-10-16 update: retained the post-approval diagnostics and named guard regression in PR #2005, recorded the normal-condition full-file non-recurrence and final-source proof limits.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 4h 6m
- Merged PRs (30d)
- 947
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from schlessera/brain-kit
-
area: backends type: docs
Difficulty 1/5 1-3 hours Newbie friendliness 83/100
schlessera/brain-kit#2383 ·
Maintainers usually reply within 1 day
-
agent-ready area: ci area: docs priority: p2 type: docs
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
schlessera/brain-kit#2104 · 4 comments ·
Maintainers usually reply within 1 day
-
agent-ready area: backends priority: p2 type: test
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
schlessera/brain-kit#1996 · 1 comment ·
Maintainers usually reply within 1 day
-
agent-ready area: docs priority: p2 type: docs
Difficulty 1/5 Under an hour Newbie friendliness 88/100
schlessera/brain-kit#1990 · 3 comments ·
Maintainers usually reply within 1 day
-
agent-ready area: core type: docs
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
schlessera/brain-kit#1944 ·
Maintainers usually reply within 1 day
All issues in schlessera/brain-kit
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
simkimsia/netlify-axi#19 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
subhranshudash13-dotcom/Contribo#74 ·
Maintainers usually reply within 1 day
-
enhancement frontend good first issue Stellar Wave trivial
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Godgift-care/sci-healthcare-frontend#166 · 1 comment ·
Maintainers usually reply within 1 day
-
backend good first issue security Stellar Wave trivial
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Godgift-care/sci-healthcare-backend#171 · 1 comment ·
Maintainers usually reply within 1 day