Skip to content

Commit 690de0f

Browse files
committed
docs(expo): trim the keychain read changeset
1 parent 1253b2a commit 690de0f

1 file changed

Lines changed: 3 additions & 3 deletions

File tree

‎.changeset/keychain-read-keeps-client.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,6 @@
44

55
Fix iOS users being signed out when the keychain can't be read for a moment, for example when the app launches in the background before the device has been unlocked since a restart.
66

7-
- On iOS, `getToken()` from the `tokenCache` in `@clerk/expo/token-cache` no longer deletes the stored client token when the keychain read fails. It rejects with the keychain error instead, which also keeps tokens in app extensions. The one exception is a read that starts and fails while the app is active. That read still deletes the token and returns `null`, as before.
8-
- When reading the client token fails, from this `tokenCache` or a custom one, Clerk waits until the app is active and reads it once more before sending the request. Requests made in the background wait until the app is opened. If the second read also fails, the request fails with that error.
9-
- A custom `tokenCache` that deletes the token and returns `null` whenever a read fails still signs users out in this case. To avoid that, rethrow the error unless `AppState.currentState` is `active` both when the read starts and when it fails. A custom `tokenCache` that always rethrows makes Clerk requests fail until the token can be read again.
7+
- On iOS, `getToken()` from the `tokenCache` in `@clerk/expo/token-cache` now rejects with the keychain error instead of deleting the stored client token, unless the read starts and fails while the app is active.
8+
- When reading the client token fails, Clerk waits until the app is active and reads it again before sending the request. Requests made in the background wait until the app is opened.
9+
- If your custom `tokenCache` deletes the token and returns `null` when a read fails, it can still sign users out in this case. Rethrow the error instead, unless `AppState.currentState` is `active` both when the read starts and when it fails.

0 commit comments

Comments
 (0)