Quantize sidekiq args

[dudo]

Allows us to strip out PII for incoming job args. This could probably replace tag_args, or maybe even put the hash in tag_args?? Not sure if that would cause confusion.

[dudo]

Couple thoughts...

• secret arg does seem to be obfuscated? Though that might be a red herring.
• can't seem to get the incantation correct to show the rest of the args.
  • expected: "["random_id"]"
    got: "["?"]"

[delner]

Adding quantize and using the existing Hash quantization seems like the way to go.

Not sure about the show: :all obfuscating other args. I would write a unit test case for the Hash quantization module to test the options your passing have the expected result, and if it doesn't pass, it should help you debug why.

[dudo]

@delner will submit another PR regarding Hash quantization... the current code early outs with :all. This PR looks good to go as long as we're comfortable deprecating tag_args.

[delner]

Not sure about the breaking change in removing tag_args here. Does quantize provide an equivalent?

If so, we must....

• Have tag_args set the equivalent quantize settings (so users with tag_args are unaffected)
• Raise a warning when tag_args is accessed and suggest quantize should be used instead.
• Add appropriate documentation to GettingStarted.md
• Mark this to be deleted as a breaking change in 2.0.

If we can't do these, we shouldn't merge this as a breaking change.

[marcotc]

As a follow up to @delner's point:

• tag_args: true seems equivalent to quantize: { show: :all }. This means tag_args can be removed if we document this change. This can be done in the migration guide: https://github.com/DataDog/dd-trace-rb/blob/master/docs/UpgradeGuide.md#breaking-changes (in a new Integrations - Sidekiq row in the upgrade guide table)

@dudo if this is addressed, as well as restoring the per-worker configuration, I think this will be good to merge!

Thank you again for your work!

[marcotc]

Thank you so much, @dudo!

[marcotc]

👋 @dudo, this change has been released in v1.1.0.
Thank you again! 🙇

[agrobbin]

@marcotc @dudo what is the expected behavior of these quantized arguments when using Sidekiq with a framework like Active Job, which uses a wrapper worker class to function? job['args'] will look something like this:

[
  {
    "job_class"=>"FooJob",
    "job_id"=>"18a1bfcc-8597-4715-9892-6b658e44eb07",
    "provider_job_id"=>nil,
    "queue_name"=>"default",
    "priority"=>nil,
    "arguments"=>[...],
    "executions"=>0,
    "exception_executions"=>{},
    "locale"=>"en",
    "timezone"=>"UTC",
    "enqueued_at"=>"2022-07-10T03:00:35Z"
  }
]

If I'm reading this code correctly, all of those "args" will be quantized and sent as job span tags, which seems unexpected.

For reference, Sidekiq itself does its best to parse arguments from known wrappers to display in the web UI. That said, it doesn't hide the argument serialization details which might be useful in this situation (i.e. _aj_symbol_keys, _aj_serialized, etc.).

[marcotc]

@agrobbin, you mention a very pertinent case.
If the arguments are wrapped in a known format, I believe we should handle the most common ones, like you linked in the official Sidekiq UI.

I'll open an issue to track this improvement.

[marcotc]

Captured here #2255.