Ah, interesting. Sure, this can definitely happen in the code, though it doesn't typically come up too often. In your case the frequent reassignments are probably causing this to occur more often.

I suspect that in most such cases, the waitrepo tasks are all going to get the same repo request id, so the only redundancy here is the stray waitrepo task which is a very low weight task.

consuming a slot on the builders

So, there are two major limits on tasks getting onto builders. The main one is host capacity vs task weight. These are abstract measures/estimates of overall system load. The waitrepo task has a weight of 0.2, so it doesn't consume much of the builder's capacity in general.

Otoh, there is also the MaxJobs settings for each builder. This is purely a task count. It serves as a safety net on the capacity limit. It is safe to set MaxJobs fairly high. The default is 10, but should be safe to raise it quite a bit higher if this layer of "builder slots" is causing an issue.

Anyway, suffice to say, having some of these duplicate waitrepo tasks shouldn't necessarily cause a strain on the builders.

All that said, I think it should be safe to make this subtask a labeled one so that it will not be recreated on task restart. This wasn't much of an issue historically, but the shift to on demand repos in 1.35 has made these subtasks much more frequent. I'll work on a PR

In our case all builders are configured with maxjobs=1 mainly for performance reasons. Each new waitrepo tasks grabs a new board thus slowing down/stopping progress in Koji.

We have to use maxjobs=1 to avoid landing two buildArch tasks causing both builds to fail. The lowest capacity per host on Koji is 1.5 IIRC. All new Koji builds (without previous records) give 1.5 weight. When we tested (on older Koji versions) Koji doesn't limit <= 1.5 capacity when assigning tasks and stop once you cross 1.5 weight. TL;DR using capacity/weight we couldn't stop Koji from landing two buildArch (each 1.5 weight) tasks on a single host.

In general it shouldn't be a problem to land buildArch and a low-weight (0.20) task on the same host.

What we tried to do was to have waitrepo, tagBuild, build, etc. (low-weight, basically 0.20) to be redirected to x86_64 node (high capacity, high maxhjobs) using Koji Hub policies to avoid them landing on riscv64 nodes. That broke Koji, but I don't recall in which way.

Simply put we don't want low-weight tasks on riscv64 nodes. We basically limit those nodes to buildArch tasks, and we can have only one per node.

I think, the problem we had with redirecting low-weight tasks to a specific channel (generic, which only holds x86_64 nodes) was that sub-tasks also inherited generic channel instead of going to default. Thus all buildArch tasks were sent to generic which had no riscv64 nodes.

We really want to "pool" waitrepo, tagBuild, build, newRepo, createrepo, etc. to x86_64 nodes which are never used for building packages.

Thus we do a lot of manual reshuffling of tasks to specific nodes. Basically external scheduling.

Simply put we don't want low-weight tasks on riscv64 nodes.

You could use a custom channel policy to force low-weight noarch tasks like waitrepo into a channel that doesn't include risc64 hosts. The default policy places child tasks in their parent's channel, but you can change that.

At any rate, #4467 should address this particular issue

Commit cd3a1e10 fixes this issue

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/4464

Please continue any further discussion there.