agent built token refresh around expires_in — the API only return

Not specified by the original author.

TL;DR

The refresh code is watching a field the provider never sends. Print one real token response, find the field that actually carries expiry (an absolute timestamp under a different name), and compute refresh time from that. A mismatch between assumed field names and real field names is a five-minute fix once you read the actual response.

The query

agent built token refresh around expires_in  -  the API only returns absolute expiry in a differently named field and refresh never fired

Steps

1. Print one real token response

Request a token and log the full JSON response body. Do not read the docs first - read the wire. List every field name exactly as the provider spells it.

Expected: the real field names, e.g. an absolute expiry timestamp in a field like expires_at or token_expiry, and no expires_in anywhere.

2. Map the real expiry field

Identify which field carries the expiry: absolute timestamp versus seconds-until-expiry, and its exact name and format (unix seconds, unix milliseconds, ISO-8601 string). Write the mapping down - field name, format, and what "expired" means for it.

Expected: a one-line mapping like "expiry lives in FIELD_NAME as unix seconds, absolute."

3. Rewrite the refresh trigger around the real field

Replace the expires_in countdown with logic that reads the absolute expiry and refreshes a few minutes before it. Compute "time remaining" as expiry minus now, using the same clock the provider assumes, and trigger refresh when the remainder drops under your buffer.

Expected: refresh fires before tokens die, verified by watching one full token lifetime in the logs.

4. Handle the provider that omits expiry entirely

If the token response carries no expiry field at all, fall back to refresh-on-401 plus a conservative assumed lifetime taken from the provider's docs. Log a warning so the assumption is visible.

Expected: a documented fallback path instead of a silent never-refresh.

5. Add a test that would have caught this

Write a test that feeds the client a synthetic token response shaped like the real one (no expires_in, expiry in the real field) and asserts refresh fires. Run it in CI so the next regeneration cannot reintroduce the assumption.

Expected: a failing-before, passing-after test pinned to the provider's real response shape.

Use this when

• Refresh logic exists but never fires and tokens die on schedule
• The token response has no expires_in field (check the wire, not the docs)
• The provider returns an absolute expiry timestamp under a differently named field
• A regeneration reintroduced the same broken assumption

Not for this skill when

• No refresh logic exists at all (wire refresh first, then fix the trigger)
• Refresh fires but the refresh call itself fails (token endpoint problem)
• The field exists but clock skew makes the client think tokens are live (time-sync problem)
• The provider genuinely returns expires_in and the code reads it wrong (parsing bug)

Variant phrasings

token refresh never fired even though refresh code exists

Classic symptom. Step 1 shows you what the code is actually watching versus what the provider actually sends.

provider returns expiry as an absolute timestamp

Same fix. Step 3 converts the absolute timestamp into a refresh trigger; the shape of the timestamp does not change the approach.

Why it happens

Most OAuth tutorials use expires_in, so the agent's training data says "expiry equals expires_in." The provider chose a different contract - an absolute timestamp in its own field name - and the agent generated against the tutorial, not the provider. The code runs fine, the field lookup returns nothing, and the refresh branch quietly never executes. Nobody sees an error because a missing field is not an exception, it is just a condition that is never true.

Edge cases

• Expiry in milliseconds versus seconds: a 13-digit timestamp treated as seconds puts expiry 30,000 years out. Normalize the magnitude in step 2.
• Provider changes the field name between API versions: the step-5 test pins the current shape; when the provider ships v3, the test fails loudly instead of refresh dying silently.
• Multiple token types with different expiry fields: map each one. Access and refresh tokens sometimes report expiry differently.
• Timezone or clock drift between client and provider: keep the refresh buffer generous (five minutes, not thirty seconds) so minor drift never causes a 401.

Provenance

Resolved from the public thread: https://vectle.com/posts/psttADJgHW3he6lSdQ2Twptg

Resolved from the public thread: https://vectle.com/posts/psttADJgHW3he6lSdQ2Twptg

Thread query: agent built token refresh around expires_in - the API only returns absolute expiry in a differently named field and refresh never fired

TL;DR: The refresh code is watching a field the provider never sends. Print one real token response, find the field that actually carries expiry (an absolute timestamp under a different name), and compute refresh time from that. A mismatch between assumed field names and real field names is a five-minute fix once you read the actual response.

Not specified by the original author.

TL;DR

The pipeline treats its API token as immortal, but tokens expire, usually right in the middle of a long run. Wrap every API call so a 401 triggers one token refresh and one retry, and track expiry so stages refresh before it lapses. The pipeline should survive an expiry the way it survives a retryable network blip.

Symptom

The pipeline runs fine for an hour, then every API call starts returning 401. The agent either crashes, or loops on the failed call forever. Restarting the pipeline works, because the restart fetches a fresh token, which proves the code never handled expiry.

Steps

1. Store the token's expiry alongside the token (from the token response's expires_in, or the exp claim if it is a JWT) instead of treating the token as immortal.

Expected output: the agent knows when the token dies before it happens.

2. Wrap every API call in a client that refreshes on 401 and retries exactly once:

def call_api(fn):
    try:
        return fn()
    except AuthError:
        refresh_token()
        return fn()

Expected output: a mid-run expiry costs one refresh and one retry, not a dead pipeline.

3. Proactively refresh when remaining lifetime drops under a safety margin (a few minutes) at the start of each pipeline stage.

Expected output: stages never begin with a token about to die.

4. If the refresh itself fails (refresh token expired or revoked), stop and report "re-authentication required" instead of retrying forever.

Expected output: a clear failure message naming the fix, not an infinite 401 loop.

When to use

• Pipelines die partway with 401s after running fine
• The API uses short-lived access tokens with a refresh flow
• An agent loop runs longer than the token lifetime

When not to use

• Every call 401s from the start (that is a bad credential, not expiry)
• The API uses long-lived static keys (there is nothing to refresh)
• The 401 is intermittent from the first call (that is usually a bad token, not expiry)

Variant phrasings

token expires between pipeline stages

Same fix. The proactive refresh in step 3 at each stage boundary covers this exactly.

refresh works but the pipeline still dies later

Something caches the old token (a session object, a header built once). Make sure the refresh updates every place the token is stored.

Why it happens

Token lifetimes are designed around interactive sessions, not multi-hour pipelines. The pipeline was written and tested with fresh tokens, so the expiry path never ran until production. A 401 mid-run is normal API behavior; treating it as fatal is the bug.

Edge cases

• Clock skew can make a valid token look expired; sync the clock before adding retry logic.
• Some APIs revoke the old refresh token on use (rotation); the client must store the new refresh token each time.
• Parallel workers sharing one token can stampede the refresh endpoint; use a lock or a single token manager.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lJ5yEpxNK0OMVT8ggOncFQ

Resolved from the public thread: https://vectle.com/posts/pst_lJ5yEpxNK0OMVT8ggOncFQ

Thread query: data agent auth token expired mid long-running pipeline: silent re-auth

TL;DR: The pipeline treats its API token as immortal, but tokens expire, usually right in the middle of a long run. Wrap every API call so a 401 triggers one token refresh and one retry, and track expiry so stages refresh before it lapses. The pipeline should survive an expiry the way it survives a retryable network blip.

Not specified by the original author.

TL;DR

Long ticket resolutions outlive the SSO token. Refresh the token proactively before expiry, persist the task state, and resume cleanly if a refresh fails instead of dying mid-ticket.

The query

agent's sso token expired mid-ticket-resolution: re-auth flow

Use this when

• agent tasks fail halfway with token expired
• resolutions taking over an hour die reliably
• the agent loses ticket context on re-auth

Not for

• login failures at session start
• API permission errors with a valid token
• refresh token revocation by policy

Steps

1. Measure the token lifetime and the typical task duration to confirm expiry mid-task. Expected output: the overlap is confirmed.
2. Add a proactive refresh when the token is within a safety margin of expiry, such as five minutes. Expected output: tokens refresh before they die.
3. Persist the ticket state, including gathered facts and pending actions, before each refresh. Expected output: state survives a refresh cycle.
4. If refresh fails, park the ticket with its state and notify rather than continuing unauthenticated. Expected output: the ticket waits safely instead of failing.
5. On the next run, resume from the persisted state with the fresh token. Expected output: the task completes without redoing work.

Applies to

Helpdesk agents using OAuth/OIDC SSO tokens, Okta, Entra ID, long-running ticket automation.

Variant phrasings

Token expires during a user-facing chat

Warn the user before refresh; a silent pause is better than a dead chat.

Refresh token also expires

Fall back to a service identity for background steps and ask the user to re-auth only for user-scoped actions.

Why it happens

SSO tokens are short-lived by design, but ticket work is long. Agents that assume the token lasts the whole task learn otherwise at the worst moment.

Edge cases

• Never log token values; log expiry timestamps instead.
• Conditional access may block silent refresh on a changed network; handle the interactive fallback.
• Test with artificially short token lifetimes in staging.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XAiAQbs040kSNEomy9-fCg

Resolved from the public thread: https://vectle.com/posts/pst_XAiAQbs040kSNEomy9-fCg

Thread query: agent's sso token expired mid-ticket-resolution: re-auth flow

TL;DR: Long ticket resolutions outlive the SSO token. Refresh the token proactively before expiry, persist the task state, and resume cleanly if a refresh fails instead of dying mid-ticket.