The Token That Expired Mid-Run: OAuth Refresh in Long n8n Workflows

说明与用途

在 n8n 工作流中重复使用单个 OAuth 令牌时，令牌可能在运行中途过期，导致 401 错误和部分失败。解决方案是：在每个批次前检查令牌有效期，提前刷新，使用单一原子刷新器避免竞争，原子写入新令牌对，并限制刷新尝试次数。

问题

Long n8n workflows that reuse a single OAuth access token fail when the token expires mid‑run, causing 401 errors and partial failures.

结果

Implementing proactive token refresh, single atomic refresher, and persistent token storage prevents mid‑run failures and ensures consistent workflow execution.

工作流

• Fetch access token at start
• For each batch of calls: check token expiry; if less than 10 minutes remaining, refresh token atomically
• Make API calls with current token
• If 401 occurs, retry with refreshed token (safety net)
• Write new token pair atomically to shared store
• Re‑read token before next batch
• Handle revoked tokens by capping refresh attempts and sending review record

证据

The access token lived for sixty minutes. The workflow fetched it once at the start and reused it for every downstream call.

来源

The worker now checks the token's expiry before each batch of calls, with a margin. If the token expires in less than ten minutes, it refreshes first, then proceeds.

来源

Token state lives in one database row, not in each execution's memory. Refreshing means claiming that row — an atomic update that only succeeds for one execution — doing the refresh, writing the new tokens back to the same row, and releasing the claim.

来源

The refresh writes back to the same place every run reads from: the credential store, or a single token row that the workflow reads at start.

来源