Hi n8n team,

I'm hitting a credential-load wedge on n8n Cloud (instance: infiniteripple.app.n8n.cloud) that's blocking production. Multiple workflows that share Google Service Account credentials stopped executing on 2026-05-17/18 and remain broken despite full credential rotation + workflow
rebuilds.

Symptom

Webhook returns HTTP 200 ("Workflow was started"), n8n creates an execution row (status="running"), but the workflow engine never picks up the queued execution. nodeExecutionStack has only the trigger queued; runData stays {} indefinitely; no nodes execute; no error is logged.
Cloudflare 524 confirms n8n never responds (sync mode).

This pattern is well-documented in your codebase as "credential-load failure" but it surfaces silently — there is no log entry indicating
which credential or which validation failed.

Affected workflows (all use the same Google SA credential)

• WF-22 Veo Video Generation (id: kCj4y0SaetTbyUU7) — last successful 2026-05-17
• WF-22.5b Draft Render Dispatch (id: G5DpNipOrfBHsLHC) — all recent: error
• WF-24 Music Generation (id: CvIjkbWa5GwzbMNR) — last successful 2026-05-18, then 3x "crashed"
• WF-25 FFmpeg Assembly (rebuilt today; id: PKTgEQOODduNibqg) — wedges identically

All four workflows share Google Service Account credential id lhpFJvl73DUOq0RG ("Google Service Account account"). The SA itself is healthy — Cloud Run jobs invoked externally with the same SA still authenticate cleanly.

Diagnostic steps already taken (none resolved it)

1. Rotated the SA key in GCP, downloaded fresh JSON, pasted PKCS#8 PEM private_key into the credential. Connection test passes (green).
   Runtime: "secretOrPrivateKey must be an asymmetric key when using RS256".
2. Toggled "Set up for use in HTTP Request node" off → save → on → save. Connection test still passes. Runtime: same error.
3. Converted the key to PKCS#1 RSA format (openssl rsa -in key.pem -out key_rsa.pem -traditional) and re-pasted. Connection test passes.
   Runtime: same error.
4. Rebuilt WF-25 from scratch (delete + POST fresh) three times — different webhook typeVersion (2 vs 2.1) and responseMode (onReceived vs
   lastNode). All wedge identically.
5. Switched WF-25's Cloud Run dispatch from googleApi credential on HTTP Request node to the LD-13 JWT pattern: Mint JWT (jwtAuth credential id 3ibY9ly6r1Cd4x5L, "AFSOR Render SA JWT") → token exchange → Bearer header. The jwtAuth credential is also affected — workflow-load wedges at webhook receipt, same empty-runData pattern.
6. Deactivate + reactivate cycle on the workflow (clears n8n webhook registration cache). No effect.

Hypothesis

n8n's credential storage/serialization for both googleApi and jwtAuth types has a per-record stale state on our instance that survives UI re-paste, format conversion, and toggle resets. The connection test code path and the runtime credential-load code path read the credential differently, and only the runtime path fails. The workflow-load wedge (no error, no log, silent failure to assign a worker) makes this very
hard to diagnose from the UI.

What we need

1. Inspect credentials lhpFJvl73DUOq0RG and 3ibY9ly6r1Cd4x5L on the back-end and confirm whether the stored key data is consistent with what the UI claims is saved.
2. If the records are corrupt: clean repair or instructions for forcing a clean re-serialization.
3. If runtime credential-load is silently failing, please add a diagnostic log so future occurrences surface visibly.

This is blocking our production render pipeline (we can't produce episodes until at least one of these workflows can fire successfully). Happy to provide more execution logs, workflow JSON dumps, or a screen-share if helpful.

Thanks,
Anshuman