-
-
Notifications
You must be signed in to change notification settings - Fork 520
Don't overwrite ip_address if already set on user #2350
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
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
|
solnic
left a comment
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.
* 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.
* 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.
* Drop `async` configuration (#1894) * Migrate from to_hash to to_h (#2351) * 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. * Fix specs after rebase * Add before_send_check_in (#2703) * Cleanup before_send to only apply to ErrorEvent * remove the Hash deprecation message * Archive sentry-raven (#2708) Moved to https://github.com/getsentry/raven-ruby * Remove stacktrace trimming from the SDK (#2714) * Default config.enabled_environments to nil instead of [] (#2716) * Remove :monotonic_active_support_logger (#2717) * Add `config.trace_ignore_status_codes` to control which status codes don't get traced (#2725) * Add config.trace_ignore_status_codes to control which status codes don't get traced * Change implementation to Range * Don't send client reports for profiles if profiling is disabled (#2728) * Remove and and all metrics related code (#2729) * Remove deprecated `config.capture_exception_frame_locals` (#2730) * Remove deprecated capture_exception_frame_locals * Remove deprecated config.enable_tracing (#2731) * Remove deprecated config.enable_tracing * Remove deprecated `config.logger` (#2732) * Remove deprecated config.logger * Remove deprecated Sentry::Rails::Tracing::ActionControllerSubscriber (#2733) * Remove Transaction deprecations (#2736) * Remove deprecated Event#configuration (#2740) * Remove deprecated client methods (#2741) * Bump required_ruby_version to 2.7 (#2743) * Bump minimum rails version in `sentry-rails` to `5.2.0` * Bump minimum sidekiq version in `sentry-sidekiq` to `5.0` * Cleanup CI * Remove hub from Transaction#initialize (#2739) * Move examples out of SDK (#2746) available at https://github.com/getsentry/examples/tree/master/ruby * Add new config.profiles_sample_interval (#2745) * Always set up the StructuredLogger and no-op capture_log_event if logs (#2752) are disabled * Make request body reading safe to rewind (#2754) * Bump oversized stacktrace trunction to 500 on both sides Revert "Remove stacktrace trimming from the SDK (#2714)" This reverts commit ed7a2db. --------- Co-authored-by: Stan Lo <stan001212@gmail.com>
Fixes #2347