Expo/JavaScript client fails in strange ways with poor or no network connectivity #3563
Comments
statico
added
the
needs-triage
|
Hey, This is also happening to us on any type of login action (oauth google/apple and sign in through email) It only seems to happen on Andriod from time to time. We did manage to fix it on some in-house testing devices by erasing all cache and deleting all data before reinstalling the app, this is not acceptable since we can't find a way to seamlessly catch or automate that for the end user. As a side note, we observe a warning at the app startup Maybe it is related to this? Our app is |
|
FWIW, our workaround is to catch this these types of errors and propagate them to the user. For example, try {
setLoading.on()
const { createdSessionId, setActive } = await startOAuthFlow()
if (createdSessionId) {
setActive?.({ session: createdSessionId })
}
} catch (err) {
const message = extractClerkErrors(err)
if (/Cannot read property 'toString' of null/.test(message)) {
log.warn(`Probable network failure: to-String-of-null error during OAuth sign-in`)
Alert.alert(
"Oops!",
`We couldn't sign you in, likely due to a network error. Please check your network connection and try again.\n\nIf you're still having trouble, please email us at [email protected]`,
)
return
}
log.error("error starting oauth flow for %s: %s", strategy, message)
Alert.alert("Sign In Error", message)
} finally {
setLoading.off()
}
// elsewhere...
export const extractClerkErrors = (error: any) => {
if (error?.errors) {
return (
"Error: " +
error.errors.map((e: any) => e.longMessage ?? e.message).join(", ")
)
} else {
return "Error: " + (error?.message ?? String(error))
}
} |
|
I wonder if this is related to the fact that Clerk mutes network errors on non-browser environments, which is the case in React Native and probably on Expo too. Because of this, in my React Native app (not Expo), network errors cause API operations to fail without throwing (it only logs an error message to the console, which is not very helpful). |
@anagstef Could this be the cause? (I'm tagging you because you created the PR which introduced this behaviour.) |
|
same for me, any update ? |
Yes, this makes Clerk network errors appear. However, I'll have to research |
|
I'm experimenting the same behavior on my Expo App
|
|
I'm getting this Network error with Expo too, usually happens when restoring the app from the background. The issue is that the auth state becomes out of sync, clerk thinks it is signed out, and as a result, the user is prompted to log in. Logging in then fails because the user is already signed in. Has anybody figured out a way to handle this? |
|
Yes. Ditch the Clerk's state handling and reimplement it yourself. Clerk in the current state is unusable on Expo, and after looking at its source code, it is not clear how this can be easily fixed. It's written by architecture astronauts, not caring at all about robustness. I'm planning to do the following:
DO NOT MOUNT CLERK. You need to get the current __clerk_client_jwt token from the token cache. If you don't have this token, goto 2. Then you need to call https://clerk.com/docs/reference/frontend-api/tag/Client#operation/getClient to get the list of active sessions, and then use the active session to call the https://clerk.com/docs/reference/frontend-api/tag/Sessions#operation/createSessionToken to get the session token. This can be done in a nice linear async/await code, without all the crazy state transitions.
|
|
Hello everyone! Thank you for opening this issue and providing information and reproduction steps. 🙏 Expo support is at the top of our priority list, so we are investigating how to resolve this without introducing breaking changes to existing apps. |
My team is having the same issue. Even when the app is open all the time, it will throw this error now and then. Operations that require our users to be logged in fail with a 401 error, it fixes itself on the second try. It seems very unstable. |
LekoArts
added
bug
|
Hello everyone! This week, in the latest version of the Example usage on ClerkProvider: <ClerkProvider
experimental={{
rethrowOfflineNetworkErrors: true
}}
/>Example of handling the error on Expo: import { isClerkRuntimeError } from "@clerk/clerk-js"
const handleSignIn = async () => {
try {
const { createdSessionId, supportedFirstFactors } = await signIn.create({
identifier: email
});
} catch (err) {
if (isClerkRuntimeError(err) && err.code === 'network_error') {
handleNetworkError();
}
}
}ref: #4525 ❗ We are still actively working on providing better support for the Offline state on Expo. Thank you everyone for providing information regarding the issues you are facing, it is very helpful and valuable for us! 🙏 Sorry for the inconvenience caused by this! |
|
I'm experiencing the same thing. It appears like the token is expiring and not properly refreshing like it does on web. |
Preliminary Checks
Reproduction
https://github.com/statico/repro-clerk-connectivity
Publishable key
pk_test_Y2xlcmsuaW5zcGlyZWQubGlvbmZpc2gtMzgubGNsLmRldiQ
Description
Steps to reproduce:
Prerequisites:
pnpm install.envfile withCLERK_PUBLISHABLE_KEY=pnpm startand then hitiorato open the app in iOS or AndroidBug No. 1
Bug No. 2
[email protected], and click "Sign In"[email protected], and click "Sign In"Expected behavior:
isLoaded. If Clerk can't load itself, we should be able to propagate an error message to the user. Checking the NetInfo module for connectivity is not enough — the internet could appear to be up, but it might just be Clerk that is inaccessible.Thanks, Clerk team!
Environment
System: OS: macOS 14.4.1 CPU: (12) arm64 Apple M2 Max Memory: 1.92 GB / 64.00 GB Shell: 5.9 - /bin/zsh Binaries: Node: 20.13.1 - ~/.nvm/versions/node/v20.13.1/bin/node npm: 10.8.1 - ~/.nvm/versions/node/v20.13.1/bin/npm pnpm: 9.1.1 - ~/.nvm/versions/node/v20.13.1/bin/pnpm Browsers: Brave Browser: 125.1.66.113 Chrome: 125.0.6422.142 Safari: 17.4.1 npmPackages: @types/uuid: 9.0.8 => 9.0.8 core-js: 3.37.1 => 3.37.1 jsdom: 24.0.0 => 24.0.0 p-limit: 5.0.0 => 5.0.0 react-select: 5.8.0 => 5.8.0 react-virtuoso: 4.7.10 => 4.7.10The text was updated successfully, but these errors were encountered: