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.