[znerol2]

What & why

The teardown fix for dmfdeploy/dmfdeploy#862 left the same two causes of a late or premature outcome on other console pages. This PR closes them.

• Hidden-tab stall. useWorkflowJobStatus (Jobs lane) stopped polling while the tab was hidden. It now polls in the background, refetches on return while the job runs, and stops once the job settles.
• Inventory lag after a job. The Provision stage and the catalog page read the catalog once after a deploy or teardown job and claimed the result while the inventory could still lag. They now say the job finished and wait for the inventory to confirm, polling every 3 s in a hidden tab too. Deploy stays unavailable while the wait is open.
  • The catalog page says the result is unconfirmed after 60 s (INVENTORY_WAIT_MS).
  • The Provision wait has no time limit, the same as the Finalise stage's existing teardown wait.
  • useCatalog now takes separate awaitingTeardown and awaitingDeploy lists. Finalise passes its existing teardown list unchanged.
• Extra fix found by a new test. After an entry's first action, the catalog page stayed on "Deploying…": its in-flight check compared the other action's IDs with null, but the first action leaves them undefined. It now uses != null.

Checks

• npm run test: 95 files, 1176 tests pass. npm run lint: 0 problems. tsc --noEmit: 0 errors.
• 11 of the 12 new tests fail on the old code. The twelfth guards against a regression.
• Mutation checks, each restored afterwards:
  • Removing refetchIntervalInBackground from useWorkflowJobStatus fails the hidden-tab Jobs lane test.
  • Removing the deploy-wait clause from useCatalog fails five tests across the catalog and Provision suites.
• Not run against a live environment.
• No separate adversarial review round: the reviewer's budget for this week is reserved for secret-handling work.

Checklist

• Commits are signed off (git commit -s).
• Commit messages follow Conventional Commits.
• VERSION bump: N/A, not a release.
• No secrets, real IPs, DNS, or operator identity.
• CI is green.
• Docs/ADRs: N/A, no decision changed.

Closes dmfdeploy/dmfdeploy#878

[lkirc]

Request changes: the Catalog confirmation flow skips successful async operations.

• frontend/src/pages/Catalog/index.tsx:588 — This OperationStatusLine only invokes callbacks for launched and error. Autoscale deploys/teardowns return watched operations; if a poll sees run_complete without the transient launched state, the *OpId never clears and handleJobComplete never starts the inventory wait/invalidation. Handle watched terminal operation states (as Provision does) and cover the Catalog run_complete path.

[znerol2]

Fixed in 583d890. Thanks, the finding was right.

• The catalog page's OperationStatusLine now also acts on the watched terminal states, taken from _WATCHED_TERMINAL_STATES rather than a second list. run_complete goes through handleJobComplete as a successful job: it clears the op id, starts the inventory wait and invalidates the catalog. Any other terminal state releases the action and starts no wait.
• It stays a local component. The shared one in JobProgress.tsx prints "Launch did not start" whenever an operation carries an error, which isn't true for a watched action that ran and then failed. Watched states take their label and colour from the shared tables.
• New tests in catalogInventoryConfirm.test.tsx:
  • a deploy whose operation goes straight to run_complete shows the waiting line, keeps Deploy unavailable, then confirms;
  • the same for a teardown;
  • a deploy that ends run_failed releases the action and claims no deployed state.
    All three fail on 69c6da4.
• Checks: npm run test 95 files and 1179 tests pass, lint 0, tsc --noEmit 0. Treating every terminal state as success fails the run_failed test.

[lkirc]

Reviewed current head 583d890. The prior Catalog terminal-operation finding is resolved; no blocking findings remain.