Returning same job id

[sasharevzin]

Is your feature request related to a problem? Please describe.
Is there a way to return the same job id when two jobs are queued with the same args and lock: :until_executed enabled?

Describe the solution you'd like
I would expect instead of returning nil when two jobs with the same args have been queued.

Describe alternatives you've considered
Not that I know

Additional context
If I lose the original job ID there is no way to get it back, so it can be checked by sidekiq status gem

[mhenrixon]

What are you after? In what situation do you want to return a job id, and which one do you want to return? We have the one that is locked and the one that is duplicated. Not entirely sure why this is an issue for you.

[sasharevzin]

I would like to return the locked one. Right now it returns nil

[mhenrixon]

The whole point with the sidekiq middleware is that returning nil allows me an easy way out.

I have had other users of sidekiq-status successfully run both gems without issue.

I also know that in some cases, with a wrong setup, people experience similar problems as you.

Could it be that you mixed up the order of the middleware somehow?

[sasharevzin]

@mhenrixon, it returns nil. Can it return the job ID instead?

[sharkey11]

@mhenrixon I agree with Sasha. Here's why.

Our Rails API endpoint returns a job ID so our frontend client can poll the status of the job by hitting an API endpoint that is connected to sidekiq status. When the job is complete (or if an error arises), the client handles it. This works if and only if the initial api endpoint returns the job ID. When the Job is in the queue, it returns nil and the client doesn't know how to handle it. But from the client's POV, the job is still not run yet and the user is still waiting. As a result we have to cache the job ID on our side using the arguments, but it would be great if sidekiq-unique-jobs handled this for us as a config option.

[mhenrixon]

@mhenrixon I agree with Sasha. Here's why.

Our Rails API endpoint returns a job ID so our frontend client can poll the status of the job by hitting an API endpoint that is connected to sidekiq status. When the job is complete (or if an error arises), the client handles it. This works if and only if the initial api endpoint returns the job ID. When the Job is in the queue, it returns nil and the client doesn't know how to handle it. But from the client's POV, the job is still not run yet and the user is still waiting. As a result we have to cache the job ID on our side using the arguments, but it would be great if sidekiq-unique-jobs handled this for us as a config option.

The problem with that approach is that I must compare the job IDs in multiple locations. It is far more brittle than the current version. Trust me, I had it like that at one point. I don't like comparing two nonsensical strings as it doesn't tell me anything. Which one is which? It takes a lot of effort to debug problems that way.

Think about instead breaking out quickly with a nil. That can be reasoned about and is conceptually easier to grasp.

I am not saying no; I am just letting you know why the gem is where it is.

[sasharevzin]

Makes sense