grape icon indicating copy to clipboard operation
grape copied to clipboard

Do not overwrite route_param with a regular one if they share same name

Open arg opened this issue 2 years ago • 9 comments

https://github.com/ruby-grape/grape/pull/2326 changed the behavior of params merging. Before v1.8.0 the following route:

resources :users do
  route_param :id do
    get do
      user = User.find(params[:id])
      { id: user.id }
    end
  end
end

would return { id: 12345 } if called as

GET /users/12345?id=1

Now, since v1.8.0, it returns { id: 1 } as id passed in params overwrites route_param.

This PR restores the previous behavior.

arg avatar Nov 23 '23 10:11 arg

@dblock could you please take a look, I made all the requested changes but PR is still in "changes requested" state for some reason.

arg avatar Nov 24 '23 13:11 arg

@arg want to finish this?

dblock avatar Dec 06 '23 15:12 dblock

@arg want to finish this?

Yes, I will. A bit busy now but will try to find some time in the next few days.

arg avatar Dec 06 '23 16:12 arg

@dblock I encountered the same issue, and if you don't mind, here's what I've found:

Why wouldn't a regular parameter specified by the caller override a route parameter?

Hashie::Mash, HashWithIndifferentAccess and Hash (prior 1.8.0) follow a similar logic: rack_params are taken as a base and overwritten with grape_routing_args (thus, grape_routing_args is strongly preferred).

NOTE: Old deep symbolize behavior, is functionally equivalent to deep_symbolize_keys

deep_symbolize_keys_in({"id" => nil}.merge(id: '123'))
#=> {:id=>"123"}

{"id" => nil}.merge(id: '123').deep_symbolize_keys
#=> {:id=>"123"}

However In Use Active support functions we replaced deep_symbolize_keys_in with deep_symbolize_keys! (with a bang), that has a bit different behavior

{"id" => nil}.merge(id: '123').deep_symbolize_keys!
#=> {:id=>nil}

The priority works for Hashie::Mash and HashWithIndifferentAccess perfectly, when Hash relies on a sequence of arguments. I agree that it was not documented, but the idea of priority of params was broken by our changes

DmytroVasin avatar Jan 04 '24 12:01 DmytroVasin

@DmytroVasin thanks for the deep dive, makes sense, let's get this PR finished and make sure we have the right specs - is there anything else missing here?

dblock avatar Jan 04 '24 17:01 dblock

@DmytroVasin thanks for the deep dive, makes sense, let's get this PR finished and make sure we have the right specs - is there anything else missing here?

@dblock so what are the changes to make? Just the API test and README note?

arg avatar Jan 04 '24 17:01 arg

I think so, basically what I said in https://github.com/ruby-grape/grape/pull/2378#pullrequestreview-1748045405. Thanks for picking this up!

dblock avatar Jan 04 '24 18:01 dblock

@arg Any updates on this?

Sorry for disturbing you, but I can proceed with completing this MR if you don't mind

DmytroVasin avatar Feb 10 '24 09:02 DmytroVasin

@dblock @DmytroVasin sorry, have been quite busy the last couple of months. So anyways, I added test to cover scenario when both route_param and regular param are defined with same nave, also added README and UPGRADING entries. Please review

arg avatar Feb 10 '24 13:02 arg

@arg Any updates on this?

Sorry for annoying you :)

DmytroVasin avatar Mar 29 '24 07:03 DmytroVasin

@DmytroVasin want to finish this PR for @arg?

dblock avatar Mar 29 '24 12:03 dblock

Hey, thanks for reminding and sorry for the delay. I’m coming back tomorrow and will try to find some time to finish the PR.

arg avatar Mar 29 '24 19:03 arg

It looks like all requested changes are applied, please review

arg avatar Mar 30 '24 08:03 arg

@dblock ready to merge

arg avatar Apr 01 '24 15:04 arg

Thanks for the good work and for hanging in here with my OCD!

dblock avatar Apr 01 '24 22:04 dblock