This aspect of scheduling is working essentially as it always has. The host runs checkHost() from the task handler just before attempting to open the task. With the new code, the host refuses the task if this check fails, letting the scheduler know that the host can't handle it.

If such task end on non-intel archs, it will timeout as builder will refuse the task.

Do you have example scheduler logs from such a case. The assigned host should reject quickly, leading the scheduler to assign it somewhere else. This might not be as fast as having multiple hosts vying to grab the task at once, but I wouldn't expect a timeout.

@tkopecek pointed me at an example. In it, there was a sequence of explicit host refusals and timeout/implicit refusal. For the explicit refusals there was about a minute delay (the default RunInterval setting) from one assignment to the next. For the implicit one it was 5 minutes, which is the default AssignTimeout.

Overall, there was a 13 minute delay as the task passed through six hosts that could not take it. That delay would have been almost halved if not for the one timeout (which was likely a host running old kojid code).

What's new here is the delay of reassignment. Previously, all ready hosts that could take the task could be trying to take it. Now, only one assigned host at a time does.

If anyone else is seeing issues like this, they could try lowering RunInterval (I suspect the default is too long anyway), and of course make sure their builders are updated.

Certainly we could like the scheduler to make more informed choices about assignments, but I'd rather not have the scheduler need to understand the meanings of individual task parameters in order to do this. We need something more systematic.

Commit 90b3ef73 relates to this ticket

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

Please continue any further discussion there.