This is a bit of an odd case, and shouldn't come up often, but we can probably do a better job.

I'm not 100% sure what the right fix here is, so tagging as discussion.

Option 1: the build task should use the event id for the repo it picks when querying tag data

This might be confusing for some ("why didn't my package build for X? it's on the tag list"), but that is probably better than failure.

Option 2: the build task could check for this case and choose to wait for an updated repo

This would avoid the previous confusion, but slow things down a little. That might also confuse people ("why is it waiting for a repo when there already is one?")

Option 3: option 1 behavior by default, but add a flag to get option 2 behavior (which could be useful for other cases as well).

It could be a part of checking for new on_demand repos. Leaving as a specific usecase.

It took me a minute to remind myself of the issue, because it looks like the code is passing a event id.

In the default case (no specific repo id passed to the build task). The builder does:

repo_info = self.getRepo(build_tag, builds=opts.get('wait_builds'),
                         wait=opts.get('wait_repo'))  # (subtask)
self.event_id = self.session.getLastEvent()['id']

So it's picking a repo (even with on demand, this repo might be a bit out of date unless wait_repo is true), but using the most recent event to query. Hence the possible misalignment.

With on_demand now merged, something option 2 is likely more reasonable. However, it's unclear what "check for this case" should look like. It could be a bit messy.