-
Notifications
You must be signed in to change notification settings - Fork 190
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
Add the ability to add arbitrary data to jobs. #383
base: master
Are you sure you want to change the base?
Conversation
…xt propogation, tags, etc
I think I had seen that. Sounds like a good idea to me |
I would like this change. In our application we've got a custom "wrapperless" ActiveJob Que adapter (instead of the default "wrapped" adapter that stores everything in |
@@ -94,13 +94,17 @@ def enqueue(*args) | |||
end | |||
end | |||
|
|||
tags = job_options[:tags] || [] | |||
data = { tags: tags }.merge(job_options[:data] || {}) | |||
# TODO: some protection about overall data size |
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.
Do we need protection for this? If people want to store arbitrarily large data here it should be allowed right? Since important indexes like que_poll_idx
and que_jobs_args_gin_idx
don't include this column, large data shouldn't have too much of an impact on performance.
@@ -94,13 +94,17 @@ def enqueue(*args) | |||
end | |||
end | |||
|
|||
tags = job_options[:tags] || [] | |||
data = { tags: tags }.merge(job_options[:data] || {}) |
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.
With this implementation you'll always get a tags key and empty array in the situation where there are no tags.
Perhaps something like this instead?
tags = job_options[:tags] ? { tags: job_options[:tags] } : {}
data = tags.merge(job_options[:data] || {})
One thing we would like to put in here is "when was a job initially scheduled" as that info is lost when a job retries. |
This is a bit of a speculative PR.. not sure of it's impact - it could be abused and I think the implementation would definitely need some checks on payload size, etc.
That said, it could be very useful for trace context propogation and prevent hacks we see here like https://github.com/open-telemetry/opentelemetry-ruby-contrib/blob/main/instrumentation/que/lib/opentelemetry/instrumentation/que/patches/que_job.rb#L26-L39
If you think it's a good idea I'll finish the implementation, and write some tests.