Ok, it appears that regenRepos is the only consumer of the data gathered by checkTasks (apart from printState, which is purely informative). So, in that sense, it seems reasonable to move this here.

On the other hand, regenRepos was was isolated to try to remove as much slowdown from the regen cycle as possible. I'm a little concerned that putting checkTasks here could have the opposite effect that intended in some cases. The getTaskInfo multicall shouldn't take very long, but the listTasks could in some instances be very slow.

Using this reraises older issue which was thought to be fixed #942. It show up more or less regularly with this patch. Not sure what is the code causing it. Even with recent_tasks_lifetime: long enough it still shows up. It will get cleared few cycles ahead when tags are updated. But meanwhile it spawns additional tasks (I've put simple continue in that part to not create secondary task as it is evidently done)

$ grep 33027713 /var/log/kojira.log
2020-11-11 13:11:59,314 [INFO] koji.repo.regen: Created newRepo task 33027713 for tag 65604 (rhel-7.9-z-nss-stack-build), expired for 160.3 sec
2020-11-11 13:17:12,659 [INFO] koji.repo.regen: Finished: newRepo task 33027713 for tag 65604
2020-11-11 14:17:18,584 [WARNING] koji: Needed tag refers to unknown task. rhel-7.9-z-nss-stack-build -> 33027713

It looks that fix could be to remove tag from needed_tags if task successfully finished. In such case it should be ok (in worst case it will be checked in next cycle, but it looks less harmful than triggerring duplicate tasks).

New issue for release #2581

I'm not 100% sure what problem we are trying to solve here.

I see that this is a followup to #2119. In that ticket, Kevin writes that the fix worked, but that Kojira was still "not functioning well". However, I don't see any details there or in that issue or in #2581.

I am concerned about dismantling this race condition fix.

Is there a problem statement somewhere that I am missing?

@kevin Are you still running this PR? Do you've hit some problems with it?

Commit 1fed5e44 fixes this pull-request

So we ran this for a while, but then went back to without it.

I think our issues were not related to this change...