recycling event ids across the various calls in a multicall can lead to some odd results. This change clears the event id cache after each call in the multicall

I thought this behavior was by design. What kind of odd results are you seeing? Also, why not just change get_event() to not cache the event_id in the context to begin with?

Hrm, I was about to say I wasn't thinking about multicall, but the docstring in get_event says different. Here's the original commit

https://pagure.io/koji/c/c277121f14944

Still not sure if persisting across multicall was intended design, or just a side effect that I convinced myself was acceptable.

The problem observed was with a script that used multicall and tagBuildBypass to do some mass tagging. The trick is that they tagged multiple builds of the same package into a tag during the multicall and this leaves the order indeterminate. Koji uses tag_listing.create_event to determine latest build.

The thinking with caching in get_event was to reflect some of the atomicity of the individual calls. For example, if one moves a build, then the create_event for the new tag is the same as the revoke event for the old one. Similar for a case where a tag operation might also add a package list entry.

Certainly worth further discussion, and if we do pull this in then I should also change the docstring on get_event()

What's the use-case for the mass-tagging? If we changed this, it sounds like the order would be defined but arbitrary. Maybe the mass-tagging script can be changed to break the tagging into more than one multicall, so the different versions are tagged in the proper order?

Use of multicall in the mass tagging was simply an optimization, as multicall usually is (ask siege for details).

The calls in a multicall are in a list and processed sequentially, so there is a well defined order of operations. I believe in the case the script had ordered the tagging in a deliberate way and the user was surprised to find that order not reflected in the system afterwards.

Certainly the script could also be changed, and I talked with siege about how he might do that, but it still seems kind of broken to me to have multiple tag listing entries with the same tag/package/create_event.

Another approach might be to add another sort key (perhaps build id desc) in readTaggedBuilds to stabilize the sort (it really bugs me that koji could report a different latest build at different times for the same event), and declare that multicalls just work this way. Perhaps we should add the extra sort key in any case.

Siege distilled the argument down to:

the end results of any calls that modify data should be the same whether they are in a multicall or not

+1