Allow rescue from parse errors

[gmcgibbon]

Related to #34287, allows parameter parse errors to be caught by rescue_from blocks.

Closes #34287.

r? @rafaelfranca

[Edouard-chin]

assert_response :ok

Could we make an assertion on the body's content to ensure that the response came from rescuing the exception

[rafaelfranca]

Should not the response be "parser error"?

[gmcgibbon]

Whoops, I'll fix that, and look into why its failing.

[gmcgibbon]

I didn't realize this at first, but it only blows up if you reference params in the controller. Is that acceptable or should we look at rescuing on the request.filtered_parameters call in instrumentation's #process_action?

[rafaelfranca]

That is the expected behavior for me.

[rafaelfranca]

This looks good to me. I'll ask other people to review too to check if I'm not missing something before merging.

cc @JoshCheek

[JoshCheek]

Oh, super exciting! I'll try it out this morning and report back with my results.

[JoshCheek]

👍

This worked for me!! Ty ty ❤️ I was able to remove my parse_action override, which was explicitly rescuing this error. A few modifications to my test suite (b/c it only raises if you reference request.request_parameters, whereas it would previously fail before making it into the action) and my entire test suite passed with this patch instead of my hack. You can see the diff here

I think it would be worth changing the example in the docs to show that you can access the original exception by receiving the parse error and asking for its #cause. I use this to allow my custom params parsers to provide helpful explanations about why the body was invalid. I think it's worth mentioning since I feel like people who want to do this are likely to also likely to want access to the original error, but I don't think it's super well known that you can use Exception#cause to do that.

rescue_from ActionDispatch::Http::Parameters::ParseError do |exception|
  render status: 400, json: { errors: [ exception.cause.message ] }
end

[gmcgibbon]

Any further comments on this @jeremy or @pixeltrix?

[pixeltrix]

Maybe clarify the behaviour here with a comment explaining that it will rescue all exceptions - it's not a construct that you see every day.

Otherwise 👍

[JoshCheek]

Ty! 🎉

[JoshCheek]

Hmm, this is on master, but not released in 5.2.2 Looking at the git tag, the released branch diverged from master on 30 Jan (explanatory comments are in pink comments at the end of each line)

The long-running separate branches seem like they're part of some intentional process like git-flow or something like that. But I read RELEASING_RAILS.md and skimmed the contribution guide and don't see an explanation, so figured I'd mention it in case it slipped through the cracks.