-
-
Notifications
You must be signed in to change notification settings - Fork 501
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
Don't overwrite ip_address if already set on user #2350
Conversation
88f073e
to
f1c79e9
Compare
f1c79e9
to
428c502
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2350 +/- ##
=======================================
Coverage 98.66% 98.66%
=======================================
Files 205 205
Lines 13483 13486 +3
=======================================
+ Hits 13303 13306 +3
Misses 180 180
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
it "doesn't overwrite already set ip address" do | ||
Sentry.set_user({ ip_address: "3.3.3.3" }) | ||
Sentry.get_current_scope.apply_to_event(event) | ||
expect(event.to_hash[:user][:ip_address]).to eq("3.3.3.3") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sl0thentr0py note for the future - this should be event.to_h
, because to_hash
is a special coercion method that's used implicitly in some places in Ruby and may cause weird issues. For example **
uses it, see:
(ruby) {foo: "bar", **event}
{:foo=>"bar",
:event_id=>"266e3389d9b64f57b48da6f3d0969a93",
:level=>:error,
:timestamp=>"2024-07-22T16:22:13Z",
:environment=>"development",
:server_name=>"44b9b235e7c3",
:modules=>
{"rake"=>"12.3.3",
# ...
It should only be used when the object that implements it is actually a hash-like object, and events are not like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As @solnic pointed out in #2350 (comment) `to_hash` has special meaning in Ruby and could be called implicitly in contexts like double splatting argument. So we should switch to `to_h` to avoid potential issues.
As @solnic pointed out in #2350 (comment) `to_hash` has special meaning in Ruby and could be called implicitly in contexts like double splatting argument. So we should switch to `to_h` to avoid potential issues.
* Migrate from to_hash to to_h As @solnic pointed out in #2350 (comment) `to_hash` has special meaning in Ruby and could be called implicitly in contexts like double splatting argument. So we should switch to `to_h` to avoid potential issues.
* Migrate from to_hash to to_h As @solnic pointed out in #2350 (comment) `to_hash` has special meaning in Ruby and could be called implicitly in contexts like double splatting argument. So we should switch to `to_h` to avoid potential issues.
Fixes #2347