The error in question is likely indeed a misconfiguration; if you’re using social connections a good first step for anything beyond a simple try login in the dashboard is to confirm that the social connection is configured with your own keys. As in, not using developer keys (https://auth0.com/docs/connections/social/devkeys) as those can be a source of issues in some scenarios.
In relation to the question itself, I’m afraid it may be slightly complicated. A login may fail at distinct stages, in particular, if it involves a social provider you can roughly think of the following stages:
- a login session at the client application.
- a login session at the Auth0 domain (which is acting as an authentication broker).
- a login session at the upstream provider.
In addition to that, within each of the above there can also be different mini-stages; for example, the login flow in Auth0 may also include MFA, consent, redirect rules. With all of this in mind a definitive answer to the question may be complex because depending in which stage it fails some stages may have completed with success and as such a valid session may be established which allows those stages to be skipped in subsequent attempts.
In my opinion I would say a client application will need to be aware of the context; as in, a user tries to login and it fails. As a first option, allowing the user to simply retry the login may suffice, however, if the user chooses that and the application receives the same thing as before it may then offer a few more options or perform something differently.
For example, once an application detects what it considers is anomalous loop where repeating the operation just leads to the same outcome it may either offer an option to login with a different account where the authentication request (assuming OIDC protocol here) would include a
prompt=login parameter that would force the login page in Auth0 to always be shown or it could perform a logout before attempting to retry the operation.