responders icon indicating copy to clipboard operation
responders copied to clipboard

Providing status as option doesn't work in 3.1.0 if has_errors?

Open unavailabl3 opened this issue 3 years ago • 2 comments

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)

unavailabl3 avatar Apr 13 '23 10:04 unavailabl3

It seems that this precious stone has been abandoned.

Viktor-Ivliev avatar Aug 01 '25 13:08 Viktor-Ivliev

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

unavailabl3 avatar Aug 01 '25 13:08 unavailabl3

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)

carlosantoniodasilva avatar Jan 23 '26 16:01 carlosantoniodasilva