Long-running REST flow returns 401 sixty minutes into the run
FieldOps Cloud exposes a REST API secured with OAuth 2.0 client credentials, and access tokens live 3,600 seconds. The integration runs every 15 minutes; the 02:00 run processes about 12,000 work orders, calling GET /workorders/{id}/history once per order and taking roughly 55 minutes. Since volume grew, about 400 calls per long run fail with HTTP 401 'invalid_token', always starting 58–62 minutes in. Short runs never fail. The connection uses an OAuth 2.0 client-credentials security policy, but the developer also added an HTTP header 'Authorization: Bearer ${accessToken}' populated from a separate token-invoke step because 'the built-in one did not work in DEV'. The client secret is stored in a plain connection property, and the connection archive was emailed to a partner. Two other consumers share the same client ID with different scopes.
1. Explain the 401 timing and state the corrective change to the connection.
Read the worked answer
The timing is the diagnosis: 58–62 minutes is just past the 3,600-second token lifetime, and short runs never cross that boundary. A connection-level OAuth policy normally lets the adapter acquire a token and re-acquire it when it expires; the hand-built header defeats that. The variable was resolved at flow start (or by an earlier invoke step), so every subsequent call reuses a stale token. The adapter may also emit two Authorization headers, which some endpoints tolerate and others reject - behavior invisible in DEV, where every run is short.
Fix: delete the token-invoke step and the manual header, keep the OAuth 2.0 client-credentials policy on the connection with the token endpoint and the minimum scopes, and let the adapter own acquisition. Add one bounded retry on 401 that re-acquires the token, because a token can still expire across a long for-each; do not use a blind 3× loop. Verify host clock sync as well - a few minutes of skew produces 401s that look random.
2. Beyond the header, what is wrong with this design and how do you fix the credential exposure?
Read the worked answer
Two separate defects: runtime length and credential hygiene.
Runtime: 12,000 single-record calls in 55 minutes is the underlying fault; the 401 is a symptom. Use a bulk or paginated history endpoint, or split the work by time window into short runs so no invocation outlives a token - the 15-minute schedule already implies short runs are acceptable. Check the documented call rate before parallelizing.
Hygiene: the secret left the tenant in an emailed archive, so treat it as compromised. Rotate it at the provider, revoke the old value, update PROD only, and store it in OCI Vault or at minimum a confidential masked property rather than plain text. Stop exporting connections with secrets - an export should carry identifiers, not credentials. Because three consumers share one client ID with different scopes, request only what this flow needs and ask for separate client registrations per environment and consumer so one rotation cannot break the others.
3. How would you demonstrate the OAuth fix works before the next nightly run?
Read the worked answer
Force the failure in test rather than waiting for production. Ask the provider for a short-lived test token (for example 300 seconds) in a sandbox tenant, run a flow that deliberately exceeds that lifetime, and confirm zero 401s and that the token is re-acquired mid-run - visible in the activity stream's invoke details and in the provider's token endpoint logs, where you should see a second token request.
Then confirm you have not over-corrected: count token requests per run. If every record causes a token acquisition, latency and provider rate limits will suffer, so the expected pattern is one acquisition plus one refresh per run (or per batch), not 12,000. Finally, check that the manual header is truly gone by capturing one outbound request and verifying a single Authorization header, and re-test in PROD with a single low-volume window before restoring the full 12,000-record run.