Expected Behavior

As a user authenticating with MONGODB-OIDC (built-in GCP/Azure/K8s providers, or OIDC_CALLBACK / OIDC_HUMAN_CALLBACK).

I expect a failed token fetch to affect only the operation that triggered it, and the next operation needing a token to attempt a fresh callback invocation.

When a token-fetch callback rejects, for example when a cloud metadata endpoint stalls and the driver's 10s request timeout fires.

Actual Behavior and Impact

• withLock() (src/cmap/auth/mongodb_oidc/callback_workflow.ts:156) awaits lock before re-arming it, so a rejected lock stops control from ever reaching the reassignment. Every later caller throws at the entry await lock with the first caller's error and the callback is never invoked again.
• One workflow is memoized per MongoClient (src/mongo_client.ts:467, src/mongo_client_auth_providers.ts:51-64), so 100% of OIDC auth on that client fails permanently. Only restarting the process recovers.

Dependencies

• None.

Risks/Unknowns

• The throttle must still apply after a failure, or a failing provider gets hammered once per connection attempt.
• Callers queued behind a failing caller currently inherit its error; the fix gives them their own invocation.

Acceptance Criteria

Implementation Requirements

• A failed invocation must not prevent later callers from invoking the callback.
• Serialization preserved: the callback never runs concurrently.
• The 100ms throttle still applies, including after a failure.
• An abort of the throttle sleep via params.timeoutContext (src/cmap/auth/mongodb_oidc.ts:75) must not poison the lock either.
• No unhandled promise rejections; no public API or error-type change.

Testing Requirements

Unit tests in test/unit/cmap/auth/mongodb_oidc/automated_callback_workflow.test.ts, against the real AutomatedCallbackWorkflow, each confirmed to fail before the fix:

• Lone rejection, then a later caller: callback invoked again and succeeds.
• Caller queued behind a rejecting callback: gets its own invocation.
• Overlapping callers: callback never runs concurrently.
• Throttle still applies after a rejection.

Note: back-to-back synchronous calls do not reproduce the wedge, as the second caller reads the queue before the first installs its chain. The queued caller must arrive a tick later. No spec test sync needed.

Documentation Requirements

None. No user-facing docs describe the OIDC callback mutex.

Follow Up Requirements

N/A

Additional context

N/A