I have 2 workers listening to the same queue, and occasionally have them both pick up the same flow and both try to run it. Is there a way to prevent this?

Hi Gregory, Workers can both poll from the same queue - you can’t actively prevent them from both attempting to pick up the same work as that enters a whole realm of scheduling / concurrency access that would be performance decreasing - think semaphores and spin locks in the linux kernel. The workers should gracefully handle the transition (attempting to prevent state transitions from pending -> running when it’s already running on another worker), but no, you can’t actively prevent it from occurring in the first place unless you just have a single worker listening to a single pool

@Christopher Boyd is there an way we could prevent the alert, in my case I am using cloudrun jobs for execution, so it only lets 1 actually run at a time, but I get crashed alerts for second one because it can't start the job

Prevent the alert in what way? To the perspective of the worker it’s valid error - it can’t schedule work as it was successfully deterred by the API (since the state was already in running). Perhaps there is an opportunity for enhancement here maybe that attempting to schedule / transition a flow run that is already in progress returns a warning or something instead of an error (but still refuses to take action)?

I agree, I want to errors to be something that requires action, otherwise real errors/crashes will get hidden in the noise

Do you have an example of the rror you are seeing just to refresh my memory, and so I can discuss internally?