ory Error handling in native self-service flows Hi! We're trying to implement better error handling for our native self-service flow and are encountering an issue with social sign-in. What we do*:* • we initialize a self-service native flow with

createNativeLoginFlow

• the flow is updated with

updateLoginFlow

to an oidc flow, setting a provider • we forward the user to the provider returned via

422 - errorBrowserLocationChangeRequired

• the user returns to the provider specific redirect URI Here an error could happen, e.g. the JSONNET mapping does fail. When simulating the flow via the Ory provided UI, the registration mask does request the missing required fields (screenshot 1) However, when using the native flow the user is just redirected back to the application, without any error code or further information (link redirect trace - screenshot 2) Modifying the

selfservice.flows.error.ui_url

does work for other errors which occur in the flow - and allows us to custom handle a lot of errors already. Unfortunately, it did not help in this case.

How can we show a custom error UI in the case described above? Is there any way to include some information about the issue that occurred in the redirect?

Did you try to fetch the self-service flow by ID? It typically has all of these errors in the UI nodes, you can extract them from there and handle accordingly.

@steep-lamp-91158 I haven't thought about that, thank you. I should have the ID in the application from initializing the flow 🤔 Its just weird to me that the redirect contains no additional info for the application to notify that the flow failed - its quite a complex logic to determine that it must have failed only based on the default redirect URL being opened. Do you see a way to include that information somehow? I think having this behavior documented would also be beneficial.

I haven't looked into the details, but I agree with your suggestion. I'll forward this internally.

thank you!

Hi, looking into this. I assume that exchanging the code for the session token then fails, correct?

Hi @narrow-van-43826, No, we actually never even get to the step, because we are not even receiving a return token from the redirect.