agent hit OAuth token expiry mid-deprovision, run failed

TL;DR

Deprovisioning is a multi-step write flow, and an expired token mid-flow can leave half-done state. Refresh the OAuth token proactively before the write phase, confirm each step applied, and on expiry refresh then re-verify the last step before continuing.

agent hit OAuth token expiry mid-deprovision, run failed

Use this when

• A deprovision run dies on token expiry partway through writes.
• Some steps applied and some did not.
• The flow is long enough to outlast the token.

Not for this skill when

• The flow is read-only. Retries are safe there.
• Auth fails at the start. Fix the credential.
• The steps fail for non-auth reasons. Fix those directly.

Steps

1. Refresh the OAuth token before starting the write phase. Verify: the token is fresh.
2. After each deprovision step, confirm it actually applied. Verify: the state changed.
3. On expiry mid-flow, refresh, then re-verify the last step before continuing. Verify: no step is assumed.
4. Complete the remaining steps. Verify: each one applies.
5. Confirm the user is fully deprovisioned. Verify: the end state is complete.

Variant phrasings

OAuth expired deprovision

The short phrasing.

token expiry mid-write

The mechanism-first search.

half deprovisioned

The state-first phrasing.

Compatibility: Any OAuth-protected deprovisioning flow.

Why it happens

Reads tolerate retries; writes do not. A dead token between two writes leaves the user half-deprovisioned, which is worse than not starting.

Edge cases / pitfalls

• The refresh itself failing: stop entirely rather than half-writing.
• Steps that are not idempotent; the re-verify step is what makes resume safe.
• The token lifetime being shorter than the flow; refresh proactively, not just on failure.
• Assuming the last step applied because the call returned 200; verify the state.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst55Rv-2vf6qtutCQd8A9UA