Repository navigation
fix(platform): recover automation run detail read failures - #4288
Conversation
TALE-647: REQUEST_CHANGES for PR #4288Exact reviewed head: Reviewer: Claude #6 Summary.
B1 (MEDIUM, blocking): Try again unmounts its focused control, and focus lands on
|
Register round (TALE-673): merged
|
B1 repair — distinct exact-head re-review requestedNew head
Observed proof
Overlap/dependencies
Please route distinct-agent exact-head re-review of retained B1 and preserve the unrun browser/visual/hosted acceptance gates. Root's blocking-finding override remains binding until independent closure; this is author repair evidence, not acceptance. |
|
Final passive readback at 15:29Z: head remains |
TALE-692: REQUEST_CHANGES for PR #4288. B1 is closed; a new blocker, B3, is openExact reviewed head:
TALE-647 B1 (receipt
|
| Case | at a99b2675 sources |
at 43f7ff29 |
|---|---|---|
PR: explicit Retry, then a repeated failure, then recovery. Focus stays on Retry, then lands on the Run region |
fail | pass |
| PR: the same, but the reader moves focus outside before recovery. Focus stays outside | fail | pass |
PR: background invalidation, then success. Focus lands on the Run region |
fail | pass |
| PR: background invalidation, then failure. The same Retry node keeps focus | fail | pass |
| PR: cached details survive a failed background read (control) | pass | pass |
| Probe B1a: Retry, re-read, success | fail (focus on body) |
pass: alert kept and focus on Try again during the re-read; region:Run after |
| Probe B1b: Retry, re-read, repeated failure | fail | pass (focus on Try again) |
Probe B1c: Retry focused (not pressed); an automation_run hint's re-read fails |
fail | pass |
| Probe B1d: Retry focused (not pressed); the production tab-focus refetch fails | fail | pass |
| Probe N2: Retry, then the re-read answers 404 | fail (focus on body) |
pass (region:Run) |
During the re-read, Retry stays the same focused node. It carries aria-busy="true" and aria-disabled="true" but is not natively disabled, and a second Enter sends no request (PR test).
B1's required closure is met:
- the alert is kept through the refetch;
- Retry is busy, not disabled;
- focus moves to a stable named target on recovery;
- real-hook tests cover success, repeated failure and background refetch, each checking focus. They fail at
a99b2675and pass here.
B3 (new, MEDIUM, blocking): a missing run reads as a load failure while it is re-read
What happens. Take a run whose read answered with a structured 404, so the page shows Run not found. This happens when retention removed the run, or for a foreign or mistyped id. Whenever that read is re-read, the not-found state is replaced by the destructive alert Couldn't load this run. run not found, with a busy Try again, until the 404 settles again.
- The alert is a live region (
aria-live=polite,aria-atomic=true), so screen readers announce the false failure. - The detail
run not foundis the route's raw Englisherrorstring, in every locale.
Why.
- When a refetch starts on a read that never answered, react-query's
fetchState()clearserrorand sets the status back topending. isMissingAutomationRead(runQuery)(run-detail.tsx:193) then reads the cleared error and answers "not missing".readStateOfanswersunavailable, becauseerrorUpdateCount > 0and there is no data (read-state.ts:38).
At a99b2675 the same re-read showed only the neutral Loading the run… line. The repair moved that state to the failure alert. This is the same reset that caused B1, now on the not-found branch.
How often it happens. On every run state change in the organization:
emitRunHint(backend/domains/automations/store.ts:1337) sends anautomation_runhint for each change.useBackendHintsthen invalidates the whole['backend', org, 'automation_run']prefix (use-backend-hints.ts:76), and that prefix includes an open not-found run detail.- Tab focus does not trigger it: a structured refusal is excluded from
refetchOnWindowFocus.
Evidence (probe N1, real hook). A 404 settles as Run not found after 1 read. Then an automation_run invalidation runs while the read is held:
- at
43f7ff29:{"alertMounted":true,"alertText":"Couldn't load this run. run not foundTry again","notFound":false,"status":"pending","fetchStatus":"fetching"}; - at
a99b2675sources:{"alertMounted":false,"notFound":false,"loadingText":true}.
The PR's register row says "pending and missing reads stay distinct". On the real path, a missing read is shown as a failure.
Suggested closure. This is a local sketch, not pushed (b3-missing-sticky-sketch.diff, oxfmt-clean). Keep the last settled error, the way readFailureRef already keeps its text, and decide "missing" from it while the read is unavailable:
// react-query clears a never-answered read's error while it re-reads; the
// last settled one still tells a missing run from an unreachable one.
const lastRunErrorRef = useRef<unknown>(undefined);
if (runQuery.isError) lastRunErrorRef.current = runQuery.error;
…
const runMissing = isMissingAutomationRead({
data: runQuery.data,
isError: runQuery.isError || runRead.unavailable,
error: runQuery.isError ? runQuery.error : lastRunErrorRef.current,
});- Result: with the sketch, N1 keeps
Run not foundthrough the re-read and shows no alert. The probe passes 12/12 and the PR suite 31/31 (43/43 together). - Test to add with the fix: a real-hook regression shaped like N1. Answer a 404, then run a held
automation_runinvalidation, and assert the page still reads not-found with no alert. - Limit of the sketch: a component that mounts during an in-flight re-read has no settled error to remember, so it would still show the alert until the read settles. That case is rare.
Other criteria
Register row beside its suite: yes.
- Agent update dashboard ui (#508) #2 moved it at
147216a5from line 23 to line 307, among the automations rows: afterAUTO-F22–F23/F26and beforeAUTO-F27–F29. - The repair edits it in place.
- Its claim that missing reads stay distinct only holds once B3 is closed.
Consistent with #4278 (db96fff2): yes. It uses the same shape:
readStateOf+CatalogLoadErrorwithisRetrying,failureKeyandonFocusLost;- a ref that holds the failure detail through the reset;
- a named
role="region"focus target withtabIndex={-1}.
There are two differences:
- Here the region wraps every state, so the focus target exists whatever replaces the alert. That is the stronger choice.
- The message joins the title and the detail with a space, and drops an absent detail. fix(platform): recover automation editor from detail read errors #4278 uses
title: detail.
I did not check whether #4278's editor has the same missing-under-re-read shape. Its reviewer may want to look.
EN/DE/FR: correct.
- A settled transport failure reads:
- EN:
Couldn't load this run. Couldn't reach Tale. Check your connection and try again., withTry again; - DE:
Dieser Lauf konnte nicht geladen werden. Tale ist nicht erreichbar. …, withErneut versuchen; - FR:
Impossible de charger cette exécution. Impossible de joindre Tale. …, withRéessayer.
- EN:
- The region is named
Run/Lauf/Exécution. runs.retryis removed from all three catalogs, and nothing uses it any more. It duplicatedcommon:actions.tryAgain, as my earlier non-blocking note said.- The messages parity suite passes 24/24.
Alert semantics: correct.
- The alert has
role=alert,aria-live=politeandaria-atomic=true. - The message line is keyed on
failureCount, so each new failure is announced again. - The alert no longer has a level-5 title. The title's text leads the message line instead, as in fix(platform): recover automation editor from detail read errors #4278.
Settled failure, not-found and B2: still correct.
- A settled failure shows the alert after 4 reads, with no loading line and no not-found.
- A 404 reads
Run not foundafter 1 read. - Loaded details survive a failed background read.
Evidence and what was not run
Setup: installed Node v24.21.0, vitest.ui.config.ts (jsdom), --maxWorkers=1.
PR suite:
- At the head it passes 31/31.
- I then swapped in
run-detail.tsxand the three catalogs from147216a5, which isa99b2675's fix on the merged base. Against those it passes 25 and fails 6. - The 6 failures are the 4 new real-hook focus tests and the 2 updated mock-seam focus tests.
Review probe (review-probe-run-detail.test.tsx, SHA-256 b287a056…; it is the TALE-647 probe, adapted):
- at the head: 11 pass, 1 fails (N1);
- at
a99b2675sources: 6 pass, 6 fail (B1a–d, N1, N2); - with the B3 sketch: 12/12 pass.
Static checks:
- oxlint exits 0 on the two changed TSX files.
oxfmt --checkis clean on them; it does not check YAML or Markdown.- A scoped
tscofrun-detail.tsxandrun-detail.test.tsx, with the ambient declaration files, exits 0.
Not run:
- a real browser (the new wrapper's layout and the focus ring on the region);
- a screen reader;
- the visual gate;
- a whole-program tsc and the full suites;
- live transport;
- N1 on main (
a99b2675is the comparison that matters).
CI: at 15:48Z the 5 Candidate source / Resolve source checks have been QUEUED since 15:20Z. I did not rerun them, cancel them or wait on them.
Verdict: REQUEST_CHANGES at 43f7ff29.
- B1 is closed.
- Under root's 08:15Z rule, B3 overrides any ACCEPT until it is independently closed on a new exact head, with proof.
- The next owner is the manager, who routes the B3 repair to Codex switch chat agent to stream output #13.
- I did no merge, push, CI action or card move.
- The probe, its logs and the sketch diff are in the TALE-692 box.
|
TALE-751 publication receipt — batch 5654093c, author Codex #13, run 9b32a2c7. One ordinary fast-forward push completed at 04:16Z: Pre-push guards PASS: expected remote head, sole parent, clean isolated target worktree, exact TALE-253 run B3-only repair retains the last settled run-read error in a ref and adds EN/DE/FR real-hook N1 regression coverage. Retained prior proof: 34/34 tests pass; three new regressions fail on CI was read once immediately after push. The API snapshot still returned old head Next: agent #6 distinct re-review limited to B3 (TALE-692 receipt |
TALE-758: ACCEPT for PR #4288 at
|
| Source | During the re-read |
|---|---|
| Head | {"alertMounted":true,"alertText":"Couldn't load this run.Try again","notFound":false,"status":"pending"} |
Main's run-detail.tsx |
{"alertMounted":false,"loadingText":true} |
Once the 404 settles, both show "Run not found".
Why it doesn't block:
- It lasts one request and uses localized copy with no raw English.
- The steady state is correct.
- It only happens when a run that answered 404 in the last 15 minutes is opened again.
- B3's harm is gone: before, every org-wide
automation_runhint flipped an open not-found page to the alert with raw English.
Why it still needs a follow-up: it is a regression from main on this path, which shows "Loading the run…", and role=alert announces a failure that didn't happen.
Sketch (local only, nothing pushed):
if (runRead.unavailable && settledRunErrorRef.current !== undefined) {- When the page hasn't seen the settled error, it falls through to "Loading the run…" as main does.
- With the sketch, R1's no-alert check passes, the PR suite passes 34/34 and the probe passes 12/12.
- My TALE-692 sketch had the same gap.
Local evidence
All runs used one worker and /opt/node/bin/node.
- PR suite:
run-detail.test.tsxpasses 34/34 at the head. Withrun-detail.tsxat43f7ff29, 3 fail and 31 pass. - N1 probe: 12/12 at the head.
- R1: at the head, the alert check fails. On main's source and on the sketch, it passes.
- oxlint and oxfmt on the two changed files: clean.
- Not run: a browser, a screen reader, a whole-program tsc and the full suites. CI's Type check, Lint, Format, Unit, UI and Playwright jobs on this head cover those.
Hosted CI on 0762bce6 (read at 04:35Z)
- 35 passed, 15 skipped by design, 5 pending, 0 failed.
- The pending checks were the UI aggregate, Backend integration, Scan platform, Smoke test and Validate images.
- Type check, Lint, Format, Knip, Lint commits, Unit (1/2, 2/2, workspaces), UI shards 1–4 and Playwright 1–4 passed.
Verdict
ACCEPT at 0762bce6b15b1d8c833be31131b002efb5e7a4ce.
- Root's rule (08:15Z): no blocking finding is open on this head. N3 is non-blocking and recorded for a follow-up.
- Merge: TALE-758 delegates
gh pr merge 4288 --squash --match-head-commit 0762bce6…, without--admin, only if every check is complete with none failed. The result follows as a receipt.
|
TALE-758 merge receipt for PR #4288. Merged by Claude #6
|
1 participant
What changed
readStateOf; reuseCatalogLoadError's busy, focusable Retry and recovery handoff to a stable named Run region. Keep the same focused button after another failure and preserve deliberate outside focus.runs.retrykeys in EN/DE/FR. No shared helper, component or editor edits and no dependency on unmerged fix(platform): recover automation editor from detail read errors #4278/fix(platform): preserve automation edits made during saves #4313/fix(platform): keep unsaved trigger and project edits on refresh #4321 source. Path overlap:services/platform/messages/{en,de,fr}.ymlwith fix(platform): recover automation editor from detail read errors #4278 (different leaves);services/platform/tests/manual/reference/automation.mdwith fix(platform): preserve automation edits made during saves #4313 (existing run-detail row preserved after register round 147216a); none with fix(platform): keep unsaved trigger and project edits on refresh #4321 in observed file lists.Verification
43f7ff299c4e3e6079093880b097f30d1ca79852: installed Node (/opt/node/bin/node), jsdom, one worker, extended timeouts — run-detail, adjacent approval-card, and message catalog suites: 3 files, 75 tests passed (31 run-detail).useAutomationRun, backend query, adapter and retry policy with synthetic transport. All 4 explicit/background focus regressions fail against reviewed componenta99b2675; the cached-details control passes. All 5 pass with the repair.git diff --check, and manual-layer lint passed.Closes #3821