When logging in with 3rd party auth, canceling within the provider prompt will raise an uncatchable exception.
Reproduction steps:
Create an app
Turn on Users service and Sign in with Google
Add the following to the startup Form.__int__:
try:
anvil.users.login_with_form()
except Exception as e:
print("exception was caught")
Run the app and click [Sign in with Google]. (see screenshot Step 4)
Click [Cancel] (see screenshot Step 5)
Exception is raised and is not caught. Exception: FAILED TO GET ACCESS TOKEN: { "error": "invalid_request", "error_description": "Missing required parameter: code" } at anvil-services/anvil/users/__init__.py:478
The same problem occurs with Sign in with Microsoft, too. The exception string is slightly different but equally uncatchable.
We’ve investigated, and this is actually intended behaviour. The built-in login dialog is ignoring that exception deliberately, because once you cancel SSO login you should land back in the login form to allow you to try again.
The actual bug here is the printing of the internal exception we’ve already handled, and we’ll get that fixed!
Internal details: anvil.google.auth.login() is the function called by the Users Service dialog when you click “Sign in with Google”. That function does raise a real Exception you can catch if the user cancels.
The main reason this is an issue is that the exception’s still passed to our custom error handler (via set_default_error_handler) as a generic Exception. So it winds up triggering the typical “Oops something went wrong!” alert since we can’t catch it as an anvil.users.ThirdPartyLoginError (or something like that). As far as I can tell the only way to avoid that behavior is to explicitly check the value of str(err), but it’d need to be customized to handle both Google and Microsoft auth errors (and also I don’t generally trust string checks like that, too fragile).
Since it doesn’t show the red-box-of-doom in the built-in error handler (which is great!), I don’t think it should be passed to a custom error handler either. Could that change be part of the fix you implement?
I added a custom handler to the Cloneable demonstration to show it’s coming through as a generic Exception class. Hope that helps.
The fix for this will indeed prevent the exception from ending up in the default error handler, so hopefully it will fully resolve the problem. I’ll post here when that is deployed so you can give it a go.