Repository navigation
docs(ledger): record the 2026-10-12 Safari fixes on #9Z197J - #3505
Merged
Merged
Conversation
WebKit now runs in CI and its genuine failures were fixed test-side in #3492-#3494 and #3501-#3504. The last three were the same race, a keypress before React attached the handler; the update names the helper to use and the one check left (the first main run after #3504). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DCghuougzFFXRF3dQQEcYr
🤖 CodeAnt AI — Review Status
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
BigSimmo has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Contributor
|
Claude encountered an error after 2s —— View job I'll analyze this and get back to you. |
codeant-ai
Bot
added
the
size:S
Contributor
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can commit Qodo's fix in one click with committable suggestions (GitHub & GitLab) |
Contributor
PR Summary by QodoRecord Safari CI fixes and follow-up for ledger issue #9Z197J
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
Contributor
Qodo FixerNo findings are available for this PR yet. Findings appear here once Qodo has reviewed the PR. |
🏁 CodeAnt Quality Gate ResultsCommit: ✅ Overall Status: PASSEDQuality Gate Details
|
Contributor
Code Review ✅ Approved🟢 Low risk · The new ledger inbox record only updates issue-tracking documentation; it does not change executable behavior or interfaces. Docs-only update to ledger row #9Z197J recording the 2026-10-12 WebKit/Safari fixes, noting that WebKit now runs in CI and the remaining race is addressed by naming the page-readiness helper. No issues found. VerificationRules No rules evaluated Functional validation Not enabledAuto-approval Approved OptionsAuto-apply is off → Gitar will not commit updates to this branch. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Gitar |
![gitar-bot[bot]](https://avatars.githubusercontent.com/in/827041?s=60&v=4){kind=small}
Merging this PR will improve performance by 10.5%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ⚡ | medication-entities: medicationEntityMatchesInText |
4.7 ms | 4.2 ms | +10.5% |
Tip
Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.
Comparing claude/ledger-webkit-w72vlz (6cac422) with main (ac737f1)
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| "payload": { | ||
| "id": "#9Z197J", | ||
| "summary": "release-browser-matrix Firefox/WebKit failures: WebKit now runs in CI and its ~26 failures are down to intermittent timing races (2026-10-12); confirm the next main run, and the job is not in PR required so it never blocks a merge", | ||
| "detail": "UPDATE 2026-10-12 (read from main CI job logs via the GitHub MCP; WebKit cannot run in the cloud container): WebKit/Safari now launches in CI (PR #3487) and the ~26 genuine Safari failures it exposed were fixed test-side in small PRs #3492-#3494 and #3501-#3504, with no test skipped, quarantined or loosened. Main run 38300091965 (after #3503) had every Firefox, WebKit desktop, phone and tablet shard green except ONE installed-app (mobile-pwa-standalone) failure, the DSM category facet keyboard test, fixed in #3504. PATTERN: the last three failures were the same race, a keypress or fill straight after navigation before React attached the handler, which slower WebKit runners expose intermittently. Use expectHydrated (tests/playwright-settlement.ts) or the handler poll in tests/ui-clinical-ask.spec.ts before the first interaction after load. NEXT: read the release-browser-matrix jobs of the first main run after #3504; if all green, close this row. A new single failure of the same shape is the same race in another test, not an app bug. The two Firefox items in #33346A did not fail in runs 38291430591 or 38300091965 (Firefox 3/3 green both times); re-check before working that row. PRIOR DETAIL: Failure count substantially reduced by layout tolerance and settled-click repairs; main-failure-routing active. PRIOR DETAIL (restored 2026-10-09, an earlier update replaced it wholesale): UPDATE 2026-09-25 from the owner-supplied Ultimate Audit Master Report (audit F10), not reproduced offline: the WebKit phone-chrome failures include header overlay, composer visibility, scroll animation and narrow settings geometry, with one settings position measured at -140 px. Audit recommendation: audit the shared scroll controller, safe-area geometry and scroll-container ownership rather than per-test fixes. The audit duplicate-<main> finding (F08) is already resolved as the hidden streaming clone (#TWS2GD); the Specifiers mobile Axe failure and the Differentials ChunkLoadError are separate rows queued the same day. PRIOR DETAIL: UPDATE 2026-09-20 (six Firefox failures read from the job log of main run 35503893104; four now addressed, two open; no Firefox was run - see the egress row). THE COUNT AND THE CLASSIFICATION IN THIS ROW WERE BOTH WRONG. Firefox failed SIX, not five, and only THREE were tolerance, not five. FIXED AND MERGED (PR #2932): three sub-pixel artefacts - a 16px card gap measured 15.999969482421875, a 12px column gap measured 11.999954223632812, and a 48px tap target measured 47.98333740234375 against its existing 2px allowance. The first two are float error from subtracting two client rects; the third is Firefox storing layout in app units of 1/60 CSS px, so 47.98333740234375 is exactly 2879/60 - one app unit short, the smallest miss the engine can express. tests/helpers/layout-tolerance.ts holds one 0.05px tolerance, mutation-tested from both sides. No floor lowered, nothing skipped or quarantined. FIXED, MERGED as PR #2933 at 0cfdd250e on 2026-09-20, verified as an ancestor of this reconciliation - originally recorded as AWAITING MERGE because the request was queued before it landed: the fourth, ui-on-call-boards dark mode, was TEST ORDERING and not an app bug. It set the colour-scheme override while the page was still on about:blank, and Playwright Firefox does not carry that into the first navigation; the theme is resolved once pre-paint by the bootstrap in src/lib/theme.ts, so a late preference is already missed. PROOF IT IS NOT THE APP: the twelve dark assertions in ui-caring-contacts-workspace.spec.ts PASS on Firefox in this same run (tests 48, 53, 59, 65, 72, 79, 85, 100, 138, 152, 159, 169) and every one navigates first and switches scheme after. An earlier reading blamed color-scheme: light on :root and concluded dark mode was broken for every Firefox and Safari user; those twelve passes refute it. Do not reopen the design-system dark contract on this evidence. STILL OPEN: the remaining two Firefox failures are tracked separately - see the row for the document-viewer hit counter and the tools Forms panel. The eight WebKit failures are UNCHANGED and still unexamined; the six phone-chrome ones remain the likely-real-iPhone-bug reading recorded above. UPDATE 2026-09-20 (read from the GitHub job logs of the latest main release-browser-matrix run; still no local browser run, provisioning fails here as described below). THE COUNT IS 13, NOT 15: Chromium green in ~8 min; Firefox 700 passed / 5 failed in ~28 min; WebKit 696 passed / 8 failed in ~40 min. THE 2026-09-06 CONCLUSION IS HALF WRONG AND THE CORRECTION IS THE POINT OF THIS UPDATE. The Firefox half is tolerance work as recorded — one failure is provably a measurement artefact, Expected >= 12 / Received 11.999954223632812, a sub-pixel rounding difference and nothing more. THE WEBKIT HALF IS NOT. Six of the eight WebKit failures are phone scroll, header, footer and composer behaviour. WebKit is Safari engine, so on an iPhone those are candidate real user-visible bugs, not engine-geometry tolerance, and must be read as a bug report rather than assertion-loosening work. ORDER: fix the five Firefox tolerances first because they are cheap and provably artefacts, then treat the six WebKit phone-chrome failures as a defect investigation, and do that before the tablet row #6GR6B8 because the two are plausibly the same root cause. QUARANTINING IS STILL THE WRONG ANSWER, and more so now: quarantining a phone-chrome failure on Safari engine would hide a defect, not a flake. tests/flake-ledger.json is for REPRODUCED flakes, requires @quarantine in the test title, and expires every entry within 31 days — and it is currently empty by design. NOT FIXED 2026-09-18. WHY IT WAS NOT DONE: the failures are only visible by running Firefox and WebKit, and browser provisioning fails in this environment — scripts/setup-claude-cloud.sh browsers returns 403, no allowlist entry for cdn.playwright.dev. A substitute Chromium exists at /opt/pw-browsers and playwright.config.ts honours PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH, so Chromium work is possible here; the other two engines are not. Sizing this needs a machine that can run all three. Note also that this is the one thing keeping main red, so it will be the first failure the new red-main reporting (#T82ND3) raises. Historical note only: an earlier 2026-09-06 write-up used a 15-failure count and treated the whole set as deterministic geometry differences to loosen; that count and that blanket remedy are superseded by this update and must not be reapplied.", |
There was a problem hiding this comment.
Suggestion: Calling any later failure with the same symptom a test race can dismiss a real Safari defect; expectHydrated confirms hydration, not that the failed behavior is correct.
Assessment: 🟠 Major · 🔁 Occurrence: Rarely · 🏷️ Incorrect condition logic
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/outstanding-issues-inbox/8d36f1f7-498f-4965-a5dd-f2e18ecd0c6e.json
**Line:** 9:9
**Comment:**
*Incorrect Condition Logic: Calling any later failure with the same symptom a test race can dismiss a real Safari defect; `expectHydrated` confirms hydration, not that the failed behavior is correct.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6cac422c6d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "payload": { | ||
| "id": "#9Z197J", | ||
| "summary": "release-browser-matrix Firefox/WebKit failures: WebKit now runs in CI and its ~26 failures are down to intermittent timing races (2026-10-12); confirm the next main run, and the job is not in PR required so it never blocks a merge", | ||
| "detail": "UPDATE 2026-10-12 (read from main CI job logs via the GitHub MCP; WebKit cannot run in the cloud container): WebKit/Safari now launches in CI (PR #3487) and the ~26 genuine Safari failures it exposed were fixed test-side in small PRs #3492-#3494 and #3501-#3504, with no test skipped, quarantined or loosened. Main run 38300091965 (after #3503) had every Firefox, WebKit desktop, phone and tablet shard green except ONE installed-app (mobile-pwa-standalone) failure, the DSM category facet keyboard test, fixed in #3504. PATTERN: the last three failures were the same race, a keypress or fill straight after navigation before React attached the handler, which slower WebKit runners expose intermittently. Use expectHydrated (tests/playwright-settlement.ts) or the handler poll in tests/ui-clinical-ask.spec.ts before the first interaction after load. NEXT: read the release-browser-matrix jobs of the first main run after #3504; if all green, close this row. A new single failure of the same shape is the same race in another test, not an app bug. The two Firefox items in #33346A did not fail in runs 38291430591 or 38300091965 (Firefox 3/3 green both times); re-check before working that row. PRIOR DETAIL: Failure count substantially reduced by layout tolerance and settled-click repairs; main-failure-routing active. PRIOR DETAIL (restored 2026-10-09, an earlier update replaced it wholesale): UPDATE 2026-09-25 from the owner-supplied Ultimate Audit Master Report (audit F10), not reproduced offline: the WebKit phone-chrome failures include header overlay, composer visibility, scroll animation and narrow settings geometry, with one settings position measured at -140 px. Audit recommendation: audit the shared scroll controller, safe-area geometry and scroll-container ownership rather than per-test fixes. The audit duplicate-<main> finding (F08) is already resolved as the hidden streaming clone (#TWS2GD); the Specifiers mobile Axe failure and the Differentials ChunkLoadError are separate rows queued the same day. PRIOR DETAIL: UPDATE 2026-09-20 (six Firefox failures read from the job log of main run 35503893104; four now addressed, two open; no Firefox was run - see the egress row). THE COUNT AND THE CLASSIFICATION IN THIS ROW WERE BOTH WRONG. Firefox failed SIX, not five, and only THREE were tolerance, not five. FIXED AND MERGED (PR #2932): three sub-pixel artefacts - a 16px card gap measured 15.999969482421875, a 12px column gap measured 11.999954223632812, and a 48px tap target measured 47.98333740234375 against its existing 2px allowance. The first two are float error from subtracting two client rects; the third is Firefox storing layout in app units of 1/60 CSS px, so 47.98333740234375 is exactly 2879/60 - one app unit short, the smallest miss the engine can express. tests/helpers/layout-tolerance.ts holds one 0.05px tolerance, mutation-tested from both sides. No floor lowered, nothing skipped or quarantined. FIXED, MERGED as PR #2933 at 0cfdd250e on 2026-09-20, verified as an ancestor of this reconciliation - originally recorded as AWAITING MERGE because the request was queued before it landed: the fourth, ui-on-call-boards dark mode, was TEST ORDERING and not an app bug. It set the colour-scheme override while the page was still on about:blank, and Playwright Firefox does not carry that into the first navigation; the theme is resolved once pre-paint by the bootstrap in src/lib/theme.ts, so a late preference is already missed. PROOF IT IS NOT THE APP: the twelve dark assertions in ui-caring-contacts-workspace.spec.ts PASS on Firefox in this same run (tests 48, 53, 59, 65, 72, 79, 85, 100, 138, 152, 159, 169) and every one navigates first and switches scheme after. An earlier reading blamed color-scheme: light on :root and concluded dark mode was broken for every Firefox and Safari user; those twelve passes refute it. Do not reopen the design-system dark contract on this evidence. STILL OPEN: the remaining two Firefox failures are tracked separately - see the row for the document-viewer hit counter and the tools Forms panel. The eight WebKit failures are UNCHANGED and still unexamined; the six phone-chrome ones remain the likely-real-iPhone-bug reading recorded above. UPDATE 2026-09-20 (read from the GitHub job logs of the latest main release-browser-matrix run; still no local browser run, provisioning fails here as described below). THE COUNT IS 13, NOT 15: Chromium green in ~8 min; Firefox 700 passed / 5 failed in ~28 min; WebKit 696 passed / 8 failed in ~40 min. THE 2026-09-06 CONCLUSION IS HALF WRONG AND THE CORRECTION IS THE POINT OF THIS UPDATE. The Firefox half is tolerance work as recorded — one failure is provably a measurement artefact, Expected >= 12 / Received 11.999954223632812, a sub-pixel rounding difference and nothing more. THE WEBKIT HALF IS NOT. Six of the eight WebKit failures are phone scroll, header, footer and composer behaviour. WebKit is Safari engine, so on an iPhone those are candidate real user-visible bugs, not engine-geometry tolerance, and must be read as a bug report rather than assertion-loosening work. ORDER: fix the five Firefox tolerances first because they are cheap and provably artefacts, then treat the six WebKit phone-chrome failures as a defect investigation, and do that before the tablet row #6GR6B8 because the two are plausibly the same root cause. QUARANTINING IS STILL THE WRONG ANSWER, and more so now: quarantining a phone-chrome failure on Safari engine would hide a defect, not a flake. tests/flake-ledger.json is for REPRODUCED flakes, requires @quarantine in the test title, and expires every entry within 31 days — and it is currently empty by design. NOT FIXED 2026-09-18. WHY IT WAS NOT DONE: the failures are only visible by running Firefox and WebKit, and browser provisioning fails in this environment — scripts/setup-claude-cloud.sh browsers returns 403, no allowlist entry for cdn.playwright.dev. A substitute Chromium exists at /opt/pw-browsers and playwright.config.ts honours PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH, so Chromium work is possible here; the other two engines are not. Sizing this needs a machine that can run all three. Note also that this is the one thing keeping main red, so it will be the first failure the new red-main reporting (#T82ND3) raises. Historical note only: an earlier 2026-09-06 write-up used a 15-failure count and treated the whole set as deterministic geometry differences to loosen; that count and that blanket remedy are superseded by this update and must not be reapplied.", |
There was a problem hiding this comment.
When this request is reconciled, the permanent ledger will attribute the WebKit fixes to PRs #3492–#3494 and #3501–#3504. Repository history shows that #3494 only changes the SQL-stripper performance test, while omitted PR #3497 is the change that settles three Safari release-matrix failures. This makes the incident provenance misleading for future diagnosis; replace the ranges with the exact relevant PRs, including #3497 and excluding #3494.
Useful? React with 👍 / 👎.
| "payload": { | ||
| "id": "#9Z197J", | ||
| "summary": "release-browser-matrix Firefox/WebKit failures: WebKit now runs in CI and its ~26 failures are down to intermittent timing races (2026-10-12); confirm the next main run, and the job is not in PR required so it never blocks a merge", | ||
| "detail": "UPDATE 2026-10-12 (read from main CI job logs via the GitHub MCP; WebKit cannot run in the cloud container): WebKit/Safari now launches in CI (PR #3487) and the ~26 genuine Safari failures it exposed were fixed test-side in small PRs #3492-#3494 and #3501-#3504, with no test skipped, quarantined or loosened. Main run 38300091965 (after #3503) had every Firefox, WebKit desktop, phone and tablet shard green except ONE installed-app (mobile-pwa-standalone) failure, the DSM category facet keyboard test, fixed in #3504. PATTERN: the last three failures were the same race, a keypress or fill straight after navigation before React attached the handler, which slower WebKit runners expose intermittently. Use expectHydrated (tests/playwright-settlement.ts) or the handler poll in tests/ui-clinical-ask.spec.ts before the first interaction after load. NEXT: read the release-browser-matrix jobs of the first main run after #3504; if all green, close this row. A new single failure of the same shape is the same race in another test, not an app bug. The two Firefox items in #33346A did not fail in runs 38291430591 or 38300091965 (Firefox 3/3 green both times); re-check before working that row. PRIOR DETAIL: Failure count substantially reduced by layout tolerance and settled-click repairs; main-failure-routing active. PRIOR DETAIL (restored 2026-10-09, an earlier update replaced it wholesale): UPDATE 2026-09-25 from the owner-supplied Ultimate Audit Master Report (audit F10), not reproduced offline: the WebKit phone-chrome failures include header overlay, composer visibility, scroll animation and narrow settings geometry, with one settings position measured at -140 px. Audit recommendation: audit the shared scroll controller, safe-area geometry and scroll-container ownership rather than per-test fixes. The audit duplicate-<main> finding (F08) is already resolved as the hidden streaming clone (#TWS2GD); the Specifiers mobile Axe failure and the Differentials ChunkLoadError are separate rows queued the same day. PRIOR DETAIL: UPDATE 2026-09-20 (six Firefox failures read from the job log of main run 35503893104; four now addressed, two open; no Firefox was run - see the egress row). THE COUNT AND THE CLASSIFICATION IN THIS ROW WERE BOTH WRONG. Firefox failed SIX, not five, and only THREE were tolerance, not five. FIXED AND MERGED (PR #2932): three sub-pixel artefacts - a 16px card gap measured 15.999969482421875, a 12px column gap measured 11.999954223632812, and a 48px tap target measured 47.98333740234375 against its existing 2px allowance. The first two are float error from subtracting two client rects; the third is Firefox storing layout in app units of 1/60 CSS px, so 47.98333740234375 is exactly 2879/60 - one app unit short, the smallest miss the engine can express. tests/helpers/layout-tolerance.ts holds one 0.05px tolerance, mutation-tested from both sides. No floor lowered, nothing skipped or quarantined. FIXED, MERGED as PR #2933 at 0cfdd250e on 2026-09-20, verified as an ancestor of this reconciliation - originally recorded as AWAITING MERGE because the request was queued before it landed: the fourth, ui-on-call-boards dark mode, was TEST ORDERING and not an app bug. It set the colour-scheme override while the page was still on about:blank, and Playwright Firefox does not carry that into the first navigation; the theme is resolved once pre-paint by the bootstrap in src/lib/theme.ts, so a late preference is already missed. PROOF IT IS NOT THE APP: the twelve dark assertions in ui-caring-contacts-workspace.spec.ts PASS on Firefox in this same run (tests 48, 53, 59, 65, 72, 79, 85, 100, 138, 152, 159, 169) and every one navigates first and switches scheme after. An earlier reading blamed color-scheme: light on :root and concluded dark mode was broken for every Firefox and Safari user; those twelve passes refute it. Do not reopen the design-system dark contract on this evidence. STILL OPEN: the remaining two Firefox failures are tracked separately - see the row for the document-viewer hit counter and the tools Forms panel. The eight WebKit failures are UNCHANGED and still unexamined; the six phone-chrome ones remain the likely-real-iPhone-bug reading recorded above. UPDATE 2026-09-20 (read from the GitHub job logs of the latest main release-browser-matrix run; still no local browser run, provisioning fails here as described below). THE COUNT IS 13, NOT 15: Chromium green in ~8 min; Firefox 700 passed / 5 failed in ~28 min; WebKit 696 passed / 8 failed in ~40 min. THE 2026-09-06 CONCLUSION IS HALF WRONG AND THE CORRECTION IS THE POINT OF THIS UPDATE. The Firefox half is tolerance work as recorded — one failure is provably a measurement artefact, Expected >= 12 / Received 11.999954223632812, a sub-pixel rounding difference and nothing more. THE WEBKIT HALF IS NOT. Six of the eight WebKit failures are phone scroll, header, footer and composer behaviour. WebKit is Safari engine, so on an iPhone those are candidate real user-visible bugs, not engine-geometry tolerance, and must be read as a bug report rather than assertion-loosening work. ORDER: fix the five Firefox tolerances first because they are cheap and provably artefacts, then treat the six WebKit phone-chrome failures as a defect investigation, and do that before the tablet row #6GR6B8 because the two are plausibly the same root cause. QUARANTINING IS STILL THE WRONG ANSWER, and more so now: quarantining a phone-chrome failure on Safari engine would hide a defect, not a flake. tests/flake-ledger.json is for REPRODUCED flakes, requires @quarantine in the test title, and expires every entry within 31 days — and it is currently empty by design. NOT FIXED 2026-09-18. WHY IT WAS NOT DONE: the failures are only visible by running Firefox and WebKit, and browser provisioning fails in this environment — scripts/setup-claude-cloud.sh browsers returns 403, no allowlist entry for cdn.playwright.dev. A substitute Chromium exists at /opt/pw-browsers and playwright.config.ts honours PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH, so Chromium work is possible here; the other two engines are not. Sizing this needs a machine that can run all three. Note also that this is the one thing keeping main red, so it will be the first failure the new red-main reporting (#T82ND3) raises. Historical note only: an earlier 2026-09-06 write-up used a 15-failure count and treated the whole set as deterministic geometry differences to loosen; that count and that blanket remedy are superseded by this update and must not be reapplied.", |
There was a problem hiding this comment.
When a later matrix run reports one interaction failure, this text instructs the reader to classify it as the same test race and not an application bug without inspecting its trace. The cited repair sequence does not support that generalization: #3502 handled a streamed replacement that remounted a panel after a tap, whereas only #3503 and #3504 established missing React handlers before keyboard input. Because an application regression can produce the same visible no-op, direct future triage to verify hydration or replacement evidence before dismissing the failure.
Useful? React with 👍 / 👎.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
User description
Summary
Before: ledger row #9Z197J still said all eight WebKit failures were open and unexamined.
After: a queued inbox update records what happened today. WebKit now runs in CI (ci: fail browser install when system libraries are missing (WebKit could not launch) #3487), and its genuine failures were fixed on the test side in test(ui): start the iPad tablet project with the iOS install hint dismissed #3492-test: time the SQL stripper as the fastest of five runs #3494 and test(webkit): wait for the settled copy after a streamed reload #3501-test(webkit): wait for the DSM filter trigger to hydrate before pressing Enter #3504. The last three failures were the same race: a keypress fired before React had attached the handler. The row names the helper to use for that, and the one remaining check, which is to read the first main run after test(webkit): wait for the DSM filter trigger to hydrate before pressing Enter #3504.
Ledger-only: one inbox request file. It reconciles into
docs/outstanding-issues.mdafter merge.Verification
npm run check:outstanding-issues("Outstanding-issues guard passed: 858 rows") andprettier --checkon the inbox file, both clean.Risk and rollout
Notes
🤖 Generated with Claude Code
https://claude.ai/code/session_01DCghuougzFFXRF3dQQEcYr
Generated by Claude Code
CodeAnt-AI Description
Update Safari CI failure tracking and next verification step
What Changed
Impact
✅ Clearer Safari test status✅ Easier identification of page-readiness test races✅ Clearer post-fix verification💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by cubic
Updates ledger row #9Z197J to record the 2026-10-12 WebKit/Safari fixes.
The queued inbox request reconciles into
docs/outstanding-issues.mdafter merge. Previously the row listed all eight WebKit failures as open and unexamined; it now notes WebKit runs in CI (#3487), the genuine failures were fixed test-side in #3492-#3494 and #3501-#3504, and the last three were the same race — a keypress fired before React attached the handler. The row namesexpectHydratedas the helper to use and leaves one remaining check: read the first main run after #3504.Written for commit 6cac422. Summary will update on new commits.