Yes, this would be appreciated. Recently I was like 30 newRepo tasks on one module... That slowed down koji a lot.

I think I just witnessed this, see screenshot below:

This would be much hard to reproduce if we deploy new MBS which contains http://pagure.io/fm-orchestrator/pull-request/1275.

The right fix is still checking if module_build.new_repo_task_id in handlers.tags.tagged is still in progress and do not start new one in that case. There is already code which can detect this in scheduler.producer.trigger_new_repo_when_stalled and can be copy-pasted.

In the scheduler.producer.trigger_new_repo_when_stalled, module_build.new_repo_task_id gets cleared if the task is active. That should probably be removed for the proposed code change to work properly.

This would be much hard to reproduce if we deploy new MBS which contains http://pagure.io/fm-orchestrator/pull-request/1275.
The right fix is still checking if module_build.new_repo_task_id in handlers.tags.tagged is still in progress and do not start new one in that case. There is already code which can detect this in scheduler.producer.trigger_new_repo_when_stalled and can be copy-pasted.

It seems to me we can also add a check in module_build_service.scheduler.handlers.tags.tagged so that the handler doesn't run if the component is already marked as tagged in the database.

Another flaw I noticed in the handler is that it doesn't verify that the component that was tagged is in the current batch that MBS is processing. So this means that in the scenario where the MBS message queue is quite large and the poller thinks MBS missed a tag message from Koji and adds a fake message in the queue, MBS could have already processed the real message by the time it sees the fake one and have moved on to the next batch.