Identity key behavior with started jobs

[rousseldenis]

@guewen do you know the reason why 'started' state is not taken into account for identity_key management?

e.g.: a started job with a long execution. A channel of four. Trigger the delay function four times. Four jobs are created even with the identity parameter.

I think that state should be taken into account too. What do you think of?

[guewen]

Hi @rousseldenis , both use cases are valid actually.
Sometimes you'd want a new job when a job is already started and sometimes you want to wait the job to be finished until you have a new one. See this discussion: #546 (comment)

So we need a way to decide whether it should be considering started jobs or not. I think it could be on queue.job.function, as it would not make any sense to have a different scope for the same job function.

[simahawk]

Job func and optional ctx key maybe?

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.