auth token expired mid-run during the agent's 4-hour close job
Fixes an auth credential expiring mid-run during an agent's 4-hour close job: split the job into checkpointed phases, refresh credentials between phases, and resume cleanly after any expiry. Use when job duration exceeds credential lifetime. Not for jobs that fail immediately on bad credentials.
TL;DR
Four hours of close work cannot fit inside a shorter credential lifetime, so the job must be built for expiry, not protected from it. Structure the close as phases, extract, match, review prep, each of which checkpoints its results and verifies its credential before starting. Between phases, refresh the credential from the approved store. If a phase still dies on expiry, it resumes from its checkpoint with a fresh credential instead of restarting the whole close.
auth token expired mid-run during the agent's 4-hour close jobUse this when
- A 4-hour close job fails with auth errors partway through after earlier phases succeeded.
- The job restarts from the beginning on retry and fails again near the same elapsed time.
- Credential lifetime is shorter than the job, for example one hour against four hours of work.
Not for this skill when
- Auth fails from the first call. The credential is wrong or revoked; fix the credential itself.
- The job could simply run faster with optimisation below the credential lifetime. If a real speedup exists, take it, and still checkpoint the job.
Steps
- Map the job into phases with natural checkpoints: extraction complete, matching complete, exceptions queued. Verify: each phase's output is inspectable independently
- Make every phase write its results durably before the next phase starts. Verify: killing the job between phases loses nothing
- Add credential refresh at phase boundaries and a validity check before each phase starts. Verify: a phase never begins with a nearly expired credential
- On an auth failure inside a phase, refresh once and resume the phase from its start checkpoint, never from the job start. Verify: a simulated expiry mid-phase recovers to completion
- Run the full 4-hour close in its phased form and confirm total auth failures handled, phases completed, and final results tied to source totals. Verify: the run completes across at least one refresh boundary with consistent results
Variant phrasings
auth expired 4 hour close job agent checkpoint resume
The long-close phrasing.
close job phases credential refresh between phases
When phasing the job.
Compatibility: OAuth-style auth for long agent close jobs spanning multiple hours.
Why it happens
Long jobs are small systems: they need their own lifecycle for credentials, state, and recovery. A four-hour job written as one script assumes the world stays still for four hours, including the auth layer, and the world does not. Phasing with checkpoints converts duration from a risk into a parameter: the job is as long as it needs to be, because each phase is short, verified, and resumable.
Edge cases / pitfalls
- Some close steps need a human credential or MFA that cannot refresh programmatically. Those phases should complete before any long automated run, with their results checkpointed.
- Phase boundaries are also quality gates: a phase that fails its tie-out should stop the close, not just refresh and continue blindly.
- Log credential refresh events in the run record; at review time the refresh trail explains gaps in request timestamps.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_yAsJPvp56G-iP3x1aK0K2w