This method should work just fine. I had some concerns before about deleting the newest vs the oldest duplicates, but it shouldn’t matter since the ErratumPackages have limited information in them. The duplicates are duplicated on their nvrea, which is the most important bit of information on the model.
The fact that no module stream erratum packages were involved makes it even more safe.
So I suppose your production server is already in the errored state with duplicates? If not, and you upgrade with the reindex, you shouldn’t need to do this cleanup on your production machine anyway.
Thanks for the confirmation.
Yes, our production machine also already is in that state. A quick SQL query shows me 327 duplicate entries. It will probably take some days until we get a downtime for it, but at least we now know how to fix that.
One tip – try to limit repository syncing and filtered content view publishing until you can run the reindexes. Until the database is reindexed, there is a chance that any model can become duplicated that shouldn’t be. In one case we even saw Pulpcore records get duplicated which could be really difficult to clean.
