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

[pacocartones]

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

• Refs feat: orchestration canvas polish (fase 2 PR-A final-review minors) #12392 (second checklist item; the issue has further bullets and stays open)

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.

[diegosouzapw]

Closing as subsumed. #12983 (orchestration canvas fase 3) landed on release/v3.8.51 and answers the same bullet of #12392 you targeted here, by a different route: instead of a carryStaleSince(prev, next) pass after the fact, buildSourceStatuses now receives the previous statuses and pins staleSince while building them.

$ git show origin/release/v3.8.51:'src/app/(dashboard)/dashboard/orchestration/hooks/useOrchestrationSnapshot.ts' | sed -n '79,81p'
  const staleSinceFor = (source: OrchSource): string => {
    ...
    return prevStatus && !prevStatus.ok && prevStatus.staleSince ? prevStatus.staleSince : nowIso;

It is fed through the functional updater form for the same reason you used one — no stale closure over statuses, no extra ref. Your diagnosis was right, including the second-order consequence: because snapshotContentKey serialises s.sources, a staleSince moving every tick re-minted the node and edge arrays that the React.memo gate exists to protect.

I checked whether your test was worth carrying over and it is already covered three times on the tip: "keeps staleSince pinned to the first failure across consecutive failing polls", "stamps a fresh staleSince when a source fails again after recovering", and "keeps snapshot referential identity across polls while a source keeps failing with an unchanged payload". Both halves of your case land inside those, so there is nothing left to port.

The rest of your batch merged today — 17 of them. Thanks for the file:line citations throughout; they made the whole set reviewable in one pass.