Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return 422 - :unprocessable_entity when form submissions fails #294

Merged
merged 2 commits into from
Sep 14, 2022

Conversation

deepakmahakale
Copy link
Member

@deepakmahakale deepakmahakale commented Sep 12, 2022

Fixes #278

Turbo requires an HTTP Status code between 400-499 or 500-599 when a FormSubmission request fails
(e.g. unprocessable entity).
This pull request makes wicked compatible with Turbo Drive.

For more details refer this pull request on rails: rails/rails#41026

This is an old pull request from @romanos - #267
Rebased and made some formatting changes

Screenshot 2022-09-14 at 11 42 13

@deepakmahakale deepakmahakale force-pushed the rebased_http_status_codes branch 2 times, most recently from 39003a2 to 12e4d1a Compare September 12, 2022 11:40
@deepakmahakale deepakmahakale changed the title Use 422 instead of 200 as the status code for failed #update action Return 422 - :unprocessable_entity when form submissions fails Sep 12, 2022
@deepakmahakale deepakmahakale force-pushed the rebased_http_status_codes branch from 12e4d1a to c071348 Compare September 14, 2022 04:16
Copy link
Member

@schneems schneems left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the change and a bunch of new tests. That's great. Testing status codes isn't an area I had previously considered but makes total sense as it's a major touchpoint.

I think this looks good to go as is. Previously you've asked about versioning. I think in this case I would consider returning a 200 response for a bad save is a bug. The desire to have it return 422 is a feature request, but I think we call this a bugfix first and a feature request second.

Technically it's a breaking change (https://www.schneems.com/2015/11/29/what-is-semver.html), in that case, we would want to rev to version 2.0. I think many projects treat the major version more as a "marketing version" and don't do true semver. It's, of course, all subjective. I personally don't mind having lots of major version changes. Jruby uses 9000 as a version number for example. Dead end is on version 4.0 already as I've been very aggressive in not breaking semver there.

I think either a 2.0 or 1.5 release is okay here. My preference would probably be to rev 2.0 "just in case".

@schneems
Copy link
Member

Forgot to add. If you rev major, I would mark the changelog entry specifically as being Breaking otherwise it's hard to see at a glance. Also I think it would be nice to say more about the "why" it was changed, specifically for compat with hotwire/turbo/turbo drive.

@deepakmahakale deepakmahakale merged commit d360aaa into main Sep 14, 2022
@deepakmahakale deepakmahakale deleted the rebased_http_status_codes branch September 14, 2022 17:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Return 422 (unprocessable entity) when form submissions fails
3 participants