Oh, sorry, I misunderstood your last post, and your analysis was exactly right. But I'm not sure if we want to add ON DELETE CASCADE to fix this; if a user tries to do --prune-replaced on a RUN that is referenced by some other CHAINED collection than the one they are modifying, it might be a sign (especially in a multi-user environment) that the RUN is important in some other context they were not aware of, and they should think twice (and then maybe use a butler command to delete it if they are sure; that doesn't exist yet, but it's DM-26684). Of course, we would need to make sure we remove it from the CHAINED collection that the user is trying to modify before deleting it, then, and I'm not sure if that's easy with the way the code is structured right now.

Ah, OK, it makes sense. I think workaround should be simple, I can call butler.registry.setCollectionChain with whatever remains in the chain after popping first element, let me try that.

Should be ready for review. I think my understanding of what the options should do is right but please check that it really should work that way.

ctrl_mpexec: https://github.com/lsst/ctrl_mpexec/pull/72

daf_butler: https://github.com/lsst/daf_butler/pull/372

Andy Salnikov am I correct in thinking that this ticket can be closed?

Indeed, I thought I closed it already.