Find out who enqueued a job and where

[amo13]

I have found myself a few times in the situation where I was debugging some error that occurred during a job and I would need to know why that job has been enqueued in the first place.
Currently, I have two jobs which got enqueued twice and I have trouble finding out why. The error itself and the stacktrace are there (thank you for integrating that feature I asked for a while back!) but the stacktrace stops where the job begins.
I can search for all occurrences of code enqueuing that specific job class in my codebase, but having an extended stacktrace crossing the boundary of the job itself would make it a lot easier to identify the correct occurence of the enqueue call and to find out why that job was enqueued in the first place.

What are your thoughts on this?

(Or is there another approach to debugging something like this?)

[Earlopain]

In GoodJob itself, there is nothing for this. I think it would be pretty expensive to store the backtrace eagerly on enqueue. Rails has some things that might help you out though.

There is active_job.log_query_tags_around_perform to write to logs where a job got enqueued from. That one is more of a dev option, and only enabled there by default. The usefulness in production doesn't seem that high.

You could also try the instrumentation api, there is an event when a job got enqueued: enqueue.active_job. It contains the job payload and may help you understand what's going on. caller should include the enqueue source (but I have not tested this).

I'm not sure how helpful this information will be to you. It sounds like you are looking at the jobs in production as these things happen but maybe it'll give you some pointers.

[amo13]

Thank you for your reply. I appreciate it. It does make sense to me and help me understand the GoodJob and Rails context.
Marking as answer.

Is there a coding pattern for enqueuing jobs in Rails which would help in such a situation? It feels like I can't be the first one looking at failed jobs but having a hard time finding out why they got enqueued.

[Earlopain]

Hm, I think labels could be used here: https://github.com/bensheldon/good_job?tab=readme-ov-file#labelled-jobs

They allow you to attach arbitrary metadata to a job, so you could add unique labels to each place you enqueue to identify later.

You can then see the info in the raw job payload behind the info icon. It's not shown in the UI I think.