Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 30 additions & 1 deletion lib/raven/integrations/sidekiq.rb
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,35 @@ def call(_worker, msg, _queue)
end
else
Sidekiq.configure_server do |config|
config.error_handlers << Proc.new {|ex,context| Raven.capture_exception(ex, :extra => {:sidekiq => context}) }
config.error_handlers << Proc.new { |ex, context|
Raven.capture_exception(ex, :extra => {
:sidekiq => filter_context(context),
})
}
end
end

def filter_context(context)
case context
when Array
context.map { |arg| filter_context(arg) }
when Hash
Hash[context.map { |key, value| filter_context_hash(key, value) }]
else
context
end
end

def filter_context_hash(key, value)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any way we can access the RESERVED_KEYS constant directly here? (I think that's what it's called)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'll dedup the knowledge of what a "forbidden" key is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I err'd on the side of being liberal and catching _aj_ prefix rather than duping the list in here and worrying about maintaining that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose the only truly maintainable solution in the long term would be to rescue SerializationErrors. Hm.

# Strip any `_aj` prefixes from keys.
# These keys come from an internal serialized object from ActiveJob.
# Internally, there are a subset of keys that ActiveJob references, but
# these are declared as private, and I don't think it's wise
# to keep chasing what this list is. But they all use a common prefix, so
# we want to strip this becuase ActiveJob will complain.
# e.g.: _aj_globalid -> _globalid
if key[0..3] == '_aj_'
key = key[3..-1]
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be better to remove the keys entirely? If the ActiveJob job to send this event to Sentry fails, the metadata will be overridden if it's re-queued, so at the very least it's not reliable data.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure if it'd be safe to strip them entirely or not. That was my initial thought, but decided it'd probably be better to err on the side of preserving as much data as possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seanlinsley's right, this is internal private state that's likely wrong/unreliable anyway. We should just drop them.

[key, filter_context(value)]
end