{"version":"2.1.242","anchor":"workload-identity-token-refresh-can-proceed-without-the-cros","canonical_anchor":"workload-identity-token-refresh-can-proceed-without-the-cros","heading":"Workload identity token refresh can proceed without the cross-process lock","tier":"internal","area":"Auth","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242\/e\/workload-identity-token-refresh-can-proceed-without-the-cros","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242","markdown":"### Workload identity token refresh can proceed without the cross-process lock\n\nWorkload identity token refresh can now go ahead without the cross-process lock rather than failing.\n\n**What**\n\nThe lock that serializes OAuth refreshes for workload identity federation now has two modes. Fail-closed retries acquisition 5 times; fail-open retries 15 and, if it still cannot get the lock, refreshes anyway without cross-process serialization rather than failing the refresh.\n\n**Details**\n\n- The fail-open path logs a debug line explaining that it proceeded unlocked.\n- The existing lock acquire and release telemetry now records which mode was in use.\n- The mode is chosen per call site, not by a user setting.\n- Workload identity client state (the credentials promise, token cache, resolved base URL and failed access tokens) moved from module globals into a resettable object.\n\n**Evidence**\n\n`wif: credentials lock unavailable at `\n\n- Area: Auth\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}