You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenTelemetry can link events which are causally related, and those links are damn useful for diagnosing weird bugs. Sidekiq integrates this nicely.
To support that, I would like to store metadata in a before_enqueue hook, so that I can link the execution of the job to the request that enqueued it (and then e.g. how long it took to run). This is different from serialized_params in that the base job class should handle it.
Storing this on good_jobs as a nullable column should add no storage overhead for users who don't use it, because the null columns bitmap doesn't need to grow to store a 23rd column. I would suggest either metadata as a jsonb column, or links as an array of text.
The text was updated successfully, but these errors were encountered:
This sounds like it could be stored in serialized_params (arbitrary data that's stored at enqueue and only used during perform). Here's an [example](https://github.com/bensheldon/good_job/discussions/901#discussioncomment-5394194) of serializing and deserializing attributes into that hash (they don't have to be passed via set` but can be grabbed via a global or wherever).
I really like OTel, but I don't see a future of adding new db columns that are solution-specific.
@DanielHeath my application has the behavior you've described, we're using opentelemetry-ruby-contrib's provided instrumentation for ActiveJob configured with the default :link propagation
OpenTelemetry can link events which are causally related, and those links are damn useful for diagnosing weird bugs. Sidekiq integrates this nicely.
To support that, I would like to store metadata in a before_enqueue hook, so that I can link the execution of the job to the request that enqueued it (and then e.g. how long it took to run). This is different from
serialized_params
in that the base job class should handle it.Storing this on good_jobs as a nullable column should add no storage overhead for users who don't use it, because the null columns bitmap doesn't need to grow to store a 23rd column. I would suggest either
metadata
as ajsonb
column, orlinks
as an array of text.The text was updated successfully, but these errors were encountered: