From aaa16305354d34f9c1f4d57253d33d9062c38faa Mon Sep 17 00:00:00 2001
From: NuklearRabbit <145918611+NuklearRabbit@users.noreply.github.com>
Date: Tue, 4 Aug 2026 17:04:33 +0200
Subject: [PATCH] docs: record WF2 retry fix and WF4's n8n-session-expiry
 blocker

---
 PROJECT_STATE.md | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md
index cab3e3f..08a3a33 100644
--- a/PROJECT_STATE.md
+++ b/PROJECT_STATE.md
@@ -1242,11 +1242,30 @@ Handler — both net-new, not yet built.
   browser automation. Whoever operates the RAGcore instance needs to look up trace
   `1955c6a8968c4941a22a1faef39e17a7` (and the earlier API rejection) in RAGcore's own
   logs to find the real cause.
+- **WF2 acceptance gap fixed and live**: continuing the acceptance pass to WF2 found it
+  had the *same* Retry On Fail gap as WF1 (its 15s timeout was already set, but retries
+  were off — the earlier note that "WF2 already had this" was wrong on the retry half).
+  Fixed live the same way (3 tries, 1000ms wait), published (version note "Add bounded
+  retries (3x) to the quality-scan HTTP call"). Repo definition and manifest checksum
+  synced (`n8n/workflows/fleet-ops-data-quality-scan.json`, `MANIFEST.md`, new checksum
+  `c0d46e0519118e6336e35c4ea2a67edb2f14bd007909ccf9256c93733751244a`, commit `167bf49`).
+- **WF4 has the same gap on its own outbound call, but is currently un-fixable**: WF4's
+  "Report failure to Fleet Ops" HTTP node also has no timeout and no Retry On Fail. Began
+  the same fix (added a 15000ms Timeout option, toggled Retry On Fail on) but n8n's
+  autosave started failing with "Unauthorized" mid-edit, and a fresh tab confirmed the
+  n8n browser session had expired (redirected to `/signin`) — so nothing was saved and
+  the live WF4 definition is unchanged from before this round (no partial/broken state).
+  This is a minor, best-effort-only gap (WF4 is the error notifier itself, not a primary
+  business flow, and it already reports failures with `On Error: Stop Workflow` so a
+  failed error-report is visible in n8n's own execution history even without retries) —
+  not blocking, but worth finishing once someone re-authenticates the n8n browser
+  session.
 - **Exact next action**: workflow 3 (RAGcore Procedure Sync) and the
   `RAGcoreKnowledgeProvider` adapter fix stay blocked on RAGcore's own credential-issuance
   rejection (not a Fleet Ops-side gap) — this is the only remaining blocker for task #86
-  and, transitively, the RAGcore-sync portion of #90/#91. Proceeding now with the parts
-  of #90 (WF1/WF2/WF4 acceptance re-check — WF1 timeout/retry gap above is fixed; WF2/WF4
-  already validated in the prior round) and #91 (final evidence doc, honestly documenting
-  workflow 3 as blocked on a RAGcore-side issue with the trace IDs above) that don't
-  depend on the credential.
+  and, transitively, the RAGcore-sync portion of #90/#91. WF1 and WF2's
+  timeouts/bounded-retries gaps are now fixed and live; WF4's matching gap on its own
+  outbound call is identified but not yet fixed (n8n browser session expired mid-edit —
+  needs re-authentication to finish, see above). Writing the final evidence doc (#91) next,
+  honestly documenting workflow 3 as blocked on RAGcore and the WF4 retry hardening as a
+  minor open follow-up.