Repository navigation
Conversation
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| request: (signal: AbortSignal) => Promise<T>, | ||
| ): Promise<T> { | ||
| const controller = new AbortController(); | ||
| const timer = setTimeout(() => controller.abort(), REQUEST_TIMEOUT_MS); |
There was a problem hiding this comment.
If a refresh request times out after acquiring a native Web Lock, its AbortError passes through the lock callback and is classified as a lock-acquisition timeout. switchToOrganization() then logs a warning and resolves even though the switch failed. getAccessToken() also retries the failed request as though it had only been waiting for the lock.
Knowledge Base Used:
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/http-client.ts
Line: 139
Comment:
**Request abort mistaken for lock timeout**
If a refresh request times out after acquiring a native Web Lock, its `AbortError` passes through the lock callback and is classified as a lock-acquisition timeout. `switchToOrganization()` then logs a warning and resolves even though the switch failed. `getAccessToken()` also retries the failed request as though it had only been waiting for the lock.
**Knowledge Base Used:**
- [Session storage and tab locking](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/authkit-js/-/docs/session-storage-and-locking.md)
- [HTTP API client](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/authkit-js/-/docs/http-api-client.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.| request: (signal: AbortSignal) => Promise<T>, | ||
| ): Promise<T> { | ||
| const controller = new AbortController(); | ||
| const timer = setTimeout(() => controller.abort(), REQUEST_TIMEOUT_MS); |
There was a problem hiding this comment.
A non-forced token request can start a proactive refresh while its current access token is still valid. If that refresh hits the new timeout on the fallback-lock path, getAccessToken() rethrows the AbortError instead of returning the valid token, so a serviceable authenticated call fails.
Knowledge Base Used:
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/http-client.ts
Line: 139
Comment:
**Valid token rejected after timeout**
A non-forced token request can start a proactive refresh while its current access token is still valid. If that refresh hits the new timeout on the fallback-lock path, `getAccessToken()` rethrows the `AbortError` instead of returning the valid token, so a serviceable authenticated call fails.
**Knowledge Base Used:**
- [HTTP API client](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/authkit-js/-/docs/http-api-client.md)
- [Client error contracts](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/authkit-js/-/docs/error-contracts.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.| grant_type: "authorization_code", | ||
| code_verifier: codeVerifier, | ||
| }, | ||
| return this.#withTimeout(async (signal) => { |
There was a problem hiding this comment.
The eight-second limit chosen for refresh-lock coordination also applies to authorization-code exchange, which does not hold that lock. If a legitimate exchange takes longer, the request is aborted, callback handling marks authentication as failed, and cleanup removes the code and stored verifier. The user cannot complete that callback even if the service was about to respond successfully.
Knowledge Base Used:
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/http-client.ts
Line: 104
Comment:
**Slow code exchanges lose callbacks**
The eight-second limit chosen for refresh-lock coordination also applies to authorization-code exchange, which does not hold that lock. If a legitimate exchange takes longer, the request is aborted, callback handling marks authentication as failed, and cleanup removes the code and stored verifier. The user cannot complete that callback even if the service was about to respond successfully.
**Knowledge Base Used:**
- [Authorization redirects and callbacks](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/authkit-js/-/docs/authorization-and-callbacks.md)
- [Client error contracts](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/authkit-js/-/docs/error-contracts.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly."Stuck" requests could hold the cross-tab refresh lock indefinitely (preventing thos OR other tabs from refreshing). This aborts API calls after 8s with a non-terminal error. Fixes #140
f98f90e to
32aecde
Compare
|
@greptile-apps update |
1 participant
"Stuck" requests could hold the cross-tab refresh lock indefinitely (preventing thos OR other tabs from refreshing). This aborts API calls after 8s with a non-terminal error.
Fixes #140