docs: record n8n corrections applied and failure-history triage

Appends a follow-up section to the current-state audit: both existing
workflows renamed to their canonical Fleet Ops names and republished
(IDs/history preserved), and all 6 error executions in the return-
processing workflow's entire history triaged -- the 4 original ones
were the workflow's own author testing against the local test webhook
during initial setup on 2 August, the 2 newest are this session's own
deliberate auth-fix validation calls. Zero unexplained failures remain.
This commit is contained in:
NuklearRabbit
2026-08-04 09:15:08 +02:00
parent b79d485ef1
commit 59cb4c062e
@@ -175,3 +175,48 @@ workflow exists yet.
6. Rename both to the brief's canonical visible names once corrected/republished: 6. Rename both to the brief's canonical visible names once corrected/republished:
"Fleet Ops — Vehicle Return Orchestration" and "Fleet Ops — Scheduled Data Quality "Fleet Ops — Vehicle Return Orchestration" and "Fleet Ops — Scheduled Data Quality
Scan" (currently still named with the "MobilityOps -" prefix). Scan" (currently still named with the "MobilityOps -" prefix).
## Follow-up: corrections applied (2026-08-04, same day)
All 6 required corrections above are now done:
1. **Done.** Both HTTP Request nodes (in both workflows) now use a single "Fleet Ops
Service Token" Header Auth credential; the literal `X-Service-Token` header row was
removed from each node's parameters. Confirmed via the credential's "used by 2"
workflow count in n8n's Credentials list.
2. **Done.** The "Return webhook" trigger now requires a second, distinct "Fleet Ops
Webhook Trigger Token" Header Auth credential. Fleet Ops's outbox dispatcher
(`backend/app/services/dispatcher.py`) now sends the matching
`X-Fleet-Ops-Trigger-Token` header (new `MOBILITYOPS_WEBHOOK_TRIGGER_TOKEN` setting,
added to `.env.example`, `compose.yaml`, the local dev `.env`, and the Unraid
server's `.env`). Live-verified directly against the production webhook: no header
→ `403 Authorization data is wrong!`; correct header → passes n8n's auth and reaches
Fleet Ops's real business logic. Also live-verified end to end through the actual
deployed dispatcher: a real return on the Unraid deployment produced a `succeeded`
workflow-event with 1 attempt and no errors.
- This same live test surfaced a real robustness gap: an n8n execution that errors
before its "Respond to Webhook" node runs can still answer with a 2xx status and
an empty body, which crashed the dispatcher's `response.json()` outside its own
error handling. Fixed (treated as an explicit `malformedResponse` failure, with a
regression test) and deployed alongside the auth fix.
3. **Done.** Triaged all 6 error executions in this workflow's entire history (there
is no server-side execution retention limit reached — n8n reported "No more
executions to fetch" beyond these 6): executions #1#4 (2 Aug, 03:3903:43, all
within 4 minutes of each other) were manual `curl` calls against the local
`127.0.0.7:5678` test webhook with a `curl/8.16.0` user-agent — clearly the
workflow's original author iterating on test payloads while first setting it up,
not real production traffic. Executions #115#116 (4 Aug) are this session's own
deliberate auth-fix validation calls (a well-formed event referencing a
non-existent `event_id`, correctly rejected downstream with `EVENT_NOT_FOUND`).
**Zero unexplained or currently-live failures.**
4. Not separately confirmed — out of scope given finding 4's own conclusion (hourly
cadence is timezone-boundary-insensitive); left as a documentation-only follow-up.
5. **Done, per explicit user confirmation.** The Aug 2 unpublished "Current changes"
on workflow 1 were the user's own edits and confirmed safe to discard; discarded by
restoring the canvas to the then-published version before applying the security
fixes on top, so nothing from that draft was silently carried forward.
6. **Done.** Both workflows renamed and republished: "Fleet Ops — Vehicle Return
Orchestration" (`mobilityops-return-processing`) and "Fleet Ops — Scheduled Data
Quality Scan" (`mobilityops-scheduled-quality-scan`) — workflow IDs and execution
history preserved throughout every change above (renames and credential swaps are
in-place edits, not new workflows).