I guess I have a question here.

so in case we have for example 10 BrewSignRPMEvents in a queue and we are handling the first one, it can happen that all the RPMs in advisory are actually signed while we are still handling message about the signing of the first one.

It can also be the case that you have 9 BrewSignRPMEvents in a queue (with 10 rpms on the advisory) and we are handling the first one. We shouldn't start building the container until the last, tenth, rpm is signed. Right?

In that case, would the code in this patch start building prematurely?

The problem is that while we are busy querying errata tool for the first BrewSignRPMEvent, all RPMs get signed. When we later start handling second BrewSignRPMEvent, we ask errata if all rpms are signed and it says "yes", so we start rebuild. Then for third BrewSignRPMEvent, we ask errata tool again if all the rpms are signed and it again says "yes" and we start rebuilding again...

To your question, it won't start building prematurely, because it always checks whether all the RPMs are signed in Errata tool. It does not count BrewSignRPMEvents anyhow, the BrewSignRPMEvent is only trigger to ask errata associated with this signed RPM whether all the rpms are signed in that advisory and if yes, start rebuild, otherwise wait for another BrewSignRPMEvent.

I see. Perfect.

So it keeps stepping through events until a query to ET says "yes".

:+1: to merge.

Yes, that's how it works.