Providing status as option doesn't work in 3.1.0 if has_errors?
After upgrading from 3.0.1 to 3.1.0 I found some changes in logic regarding providing status to respond_with.
I need to change status for a couple of actions for Hotwire/Turbo usage. There is new configuration option responders.error_status, but there is no need to set it as a default for the whole application in some cases.
I have update action in my controller:
def update
@product.update(product_params) #it will add errors on invalid params
respond_with @product, location: [:dashboard], action: :show, status: 422
end
When I was using 3.0.1 if it has errors it returns status 422, as provided.
After moving to 3.1.0 this doesn't work and status set as default 200 OK.
I didn't find in changelog that providing status via options doesn't work any more.
I found possible problem inside error_rendering_options:
def to_html
default_render
rescue ActionView::MissingTemplate => e
navigation_behavior(e) # <-- here
end
def navigation_behavior(error)
if get?
raise error
elsif has_errors? && default_action
render error_rendering_options # <-- here
else
redirect_to navigation_location, status: redirect_status
end
end
def error_rendering_options
if options[:render]
options[:render]
else
{ action: default_action, status: error_status } # <-- here
end
end
It works as previously when I tried to change it locally to:
{ action: default_action, status: options[:status] || error_status }
And probably for redirects there is possibility of the same issue and, it could be:
redirect_to navigation_location, status: (options[:status] || redirect_status)
It seems that this precious stone has been abandoned.
It seems that this precious stone has been abandoned.
I will check if it is still actual for my project and close this issue if not
I think it just happened to be that the previous hardcoded status was :unprocessable_entity, i.e. 422: https://github.com/heartcombo/responders/commit/28f1a9894f750b65a5a009d482f54e3ff399e866#diff-8e4db0a26bb3b2ba891c99d1b620b3b02ff0b1e8d8df1399e08cc1da5fb6b737R313
So we weren't accepting a status option, but it matched the one you were providing?
The status is generally accepted for the successful case, if there are no errors and we respond with ok/created/redirected/etc or the given status. But for errors it should always be 422 (or the configured error_status now)