Skip to content

fix(orchestration): keep the first staleSince while a source keeps failing - #12544

Open
pacocartones wants to merge 2 commits into
diegosouzapw:release/v3.8.51from
pacocartones:fix/orchestration-keep-first-stale-since
Open

fix(orchestration): keep the first staleSince while a source keeps failing#12544
pacocartones wants to merge 2 commits into
diegosouzapw:release/v3.8.51from
pacocartones:fix/orchestration-keep-first-stale-since

Conversation

@pacocartones

Copy link
Copy Markdown
Contributor

Summary

  • buildSourceStatuses (src/app/(dashboard)/dashboard/orchestration/hooks/useOrchestrationSnapshot.ts:63-90) stamps every failed source with the current poll's nowIso (lines 76, 79, 87), and the poll loop replaced the whole list with setStatuses(next). With the sourceStale message now live, SourceNode (nodes/SourceNode.tsx:24-28) therefore read "stale since " instead of the first error, and because snapshotContentKey serialises s.sources, the key changed on every 5s/30s tick for as long as a source was down — re-minting the node/edge arrays the React.memo gate exists to protect.
  • This is the second bullet of feat: orchestration canvas polish (fase 2 PR-A final-review minors) #12392 ("staleSince avança a cada poll"). Fix: a pure carryStaleSince(prev, next) helper (line 99) copies the previous staleSince onto a source that was already failing, applied through the functional update setStatuses((prev) => carryStaleSince(prev, next)) (line 152). A source that recovers is pushed as { ok: true } with no staleSince, so the next failure is stamped fresh; a first failure keeps this poll's nowIso. buildSourceStatuses, mergeSnapshot and the conductor offline branch are untouched.
  • Deliberately out of scope: the other bullets of feat: orchestration canvas polish (fase 2 PR-A final-review minors) #12392 (toolbar debounce race, placeholder-only stale indicator in mergeSnapshot, a11y, noMatches, particle budget, drawer error banner, toggleCsv) — each is a separate surface and the issue stays open.

Related Issues

Validation

  • Change type: UI (dashboard orchestration hook)
  • Focused tests and category gates from the golden path: ./node_modules/.bin/vitest run --config vitest.config.ts tests/unit/ui/useOrchestrationSnapshot.test.tsx 8/8; tests/unit/ui/orchestration* + the hook test 89/89 (7 files); node scripts/check/check-complexity-ratchets.mjs --base-ref origin/release/v3.8.51 OK (0 violations, cognitive 0); npm run check:changelog-integrity OK; npm run typecheck:core exit 0
  • npm run lint
  • Reconciled with the current active release base release/v3.8.51 (on top of feat(dashboard): orchestration canvas fase 2 — repeat action + A2A memory hits (2.6/2.7) #12508 / chore(quality): tighten the CodeQL ratchet baseline from 11 to 6 #12530); focused checks rerun afterward
  • Production-code changes include a new or updated automated test in this PR
  • SonarQube is temporarily opt-in while the private project has no quota; it is not a PR gate.

eslint on the two touched files exits 0 (also run by the lint-staged pre-commit hook).

Tests Added Or Updated

  • tests/unit/ui/useOrchestrationSnapshot.test.tsx — new case "keeps the first staleSince while a source keeps failing and clears it once it recovers (feat: orchestration canvas polish (fase 2 PR-A final-review minors) #12392)": ok → fail → fail → ok with fake timers. Asserts no staleSince on the healthy poll, a string on the first failure, the SAME value on the next failing poll 5s later (base fails here: expected '…:18.927Z' to be '…:13.927Z'), snapshot referential identity preserved across the two failing polls, and staleSince cleared on recovery. Red on the base (1 fail / 7 pass), green with the change (8/8). The seven existing cases are unchanged.

Coverage Notes

  • src/app/(dashboard)/dashboard/orchestration/hooks/useOrchestrationSnapshot.ts: carryStaleSince is exercised end-to-end through the hook in all three branches (first failure → keep own stamp; repeated failure → carry; recovery → drop) by the new case, plus the existing "failed source keeps the last good data" case.
  • No touched file lost coverage.

Reviewer Notes

  • Behaviour change is limited to the staleSince value while a source stays down; ok, error and offline are still refreshed every poll. error text changing between polls will still bump the content key, which is intended (it is user-visible).
  • The helper is exported only so it can be unit-tested directly later if wanted; nothing else imports it.
  • Changelog fragment: changelog.d/fixes/PENDING-orchestration-keep-first-stale-since.md — rename PENDING to the PR number after opening.

…iling

`buildSourceStatuses` stamped every failed source with the current poll's
`nowIso`, so with the `sourceStale` message live the node showed "stale
since <last poll>" instead of the first error, and `snapshotContentKey`
changed every tick for as long as a source was down. Carry the previous
`staleSince` forward through a pure `carryStaleSince(prev, next)` applied in
the functional `setStatuses` update; a recovered source has no `staleSince`,
so the next failure is stamped fresh.

Refs diegosouzapw#12392
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant