koji

#3602 Removing a package from a tag leaves the DB in an inconsistent state
Opened by alexi. Modified

Open
Close Issue

(This has been tested in 1.28.1, I haven't had a change to upgrade to the latest version yet)

If you remove a package from a tag, all it's builds will get removed from the tag but the DB is left in an inconsistent state.

For example, here's a build that belongs to a tag:

> koji buildinfo almalinux-release-8.7-3.al8.cern
BUILD: almalinux-release-8.7-3.al8.cern [58559]
State: COMPLETE
...
Tags: cern8al-testing
...
> koji list-tagged cern8al-testing | grep alma
almalinux-release-8.7-3.al8.cern          cern8al-testing       kojici

We can remove the package from the tag, and all the builds are removed as well:

> koji remove-pkg cern8al-testing almalinux-release
> koji list-tagged cern8al-testing | grep alma

However, the build itself still believes it belongs to the tag, and this can't be cleaned up;

> koji buildinfo almalinux-release-8.7-3.al8.cern
BUILD: almalinux-release-8.7-3.al8.cern [58559]
State: COMPLETE
...
Tags: cern8al-testing
...
> koji untag-build cern8al-testing almalinux-release-8.7-3.al8.cern
Build almalinux-release-8.7-3.al8.cern not in tag cern8al-testing

This inconsistency can be cleaned by re-adding the package to the tag, untagging all the builds, and then removing the package from the tag.

Hmm, we've seen this few more times this year. Probably our intended workflow is not clear enough. In such cases we expect to block the package, not removal, so inheritance (tag which inherits from this one) is not affected. There is only few usecases when remove-pkg makes better sense than blocking the package and it is safe to do.
"remove-pkg" intentionally doesn't untag the builds which are already there. Maybe we can add check + option there. Default call will trigger a warning and refuse to remove the tag if there is something tagged in. It could be overriden with --leave-builds or --untag-builds to ensure what is the expected behaviour (--force is already dealing with package_list policy).
I'm a bit worried about changing the defaults, but without it it will need the steps you've described.

@mikem ?

Metadata Update from @tkopecek:
- Custom field Size adjusted to None

I'm not sure I understood correctly, but if you don't intent to untag the builds when its package is removed, then the behaviour is still wrong: the builds are untagged, as my example shows.

Yep, it is a hidden issue - it is tagged by list-tagged will not show it as it is based on current package list thus filtering out these builds.

Then perhaps they should be filtered out as well from buildinfo?

Still, I find the behavior kind of odd. If the intention is that a removed package can't have any new builds added to a tag but the old ones are untouched, then don't hide them from list-tagged to make this clear. Leaving them tagged but hiding them in some output and making them un-untaggable is just unnecessarily confusing, I think.

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

Please continue any further discussion there.
Metadata
None
None
None
None
Low
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.