Hi! I noticed that when the login flow is updated with

identifier_first

method using kratos go sdk, a 400 status is returned (I opened a bug about that: https://github.com/ory/kratos/issues/4453). The login flow is still returned though, which is confirmed by the http docs: https://www.ory.sh/docs/kratos/reference/api#tag/frontend/operation/updateLoginFlow. Should I consider the 400 a 'successful', expected response and continue to the next login step or does that indicate a failure? Are there any other circumstances in which the identifier first flow can return a 400?

In this case 400 is considered "partial" failure/success, as the flow is not yet completed.

Thanks for your answer. It feels a bit odd to see 400 for a flow that has partially succeeded. I’d expect something like a 303 instead, which is what I see when calling the Kratos API directly. According to docs 400 is returned on form validation errors, so I guess it can be returned both on 'success' and failures

@steep-lamp-91158 this makes sense, but afaict the thing that causes the "failure" is the requested content type, while the flow was updated successfully. If I understand correctly, in some other handlers Kratos returns a 422 in such cases. Maybe it would make sense to instead return a 422 the user to the login page with the flow appended in this case as well. When someone is using the Kratos sdk it is impossible to update some flows and not get an error (

400

or

422

) back. The question is whether there is a way that we can safely decide whether Kratos returned an error because something went wrong OR if it returned an error because it is a backchannel request (like in this case).

I understand the confusion and all I can say is that I was not involved in the design of that, so I'm not sure if there are better alternatives, or if we can easily "fix" it. Generally the returned UI nodes always contain all information tied to the respective inputs, so you should be fine with simply rendering the error messages and all inputs in the frontend.