It's possible that your issue is that your kpartx call is getting messed up by the automatic kpartx call udev runs to resize the partitions. /lib/udev/rules.d/66-kpartx.rules should trigger a kpartx update on every reasonable change event to the multipath device.  Writing to the partition table with sfdisk should do that. It does for me on a RHEL system, and the kpartx paritition is automatically updated. It seems possible that manually running kpartx at the same time could attempt to update the device while the udev triggered update is in process. In that case, it could race and try to suspend the device when it had already been suspended by the other process.

So if I'm right, the issue is that there is no synchronization between your script and the udev daemon. DM devices must be in the suspended state while updating their device tables, and if the device is already in the suspend state when you try to suspend to update the table, dm will fail with exactly the error message you saw. If this is indeed what is happening, then the easiest solution is to not run kpartx, and trust udev to do this. If you needed to guarantee that udev has run, you could call "udevadm settle". If you don't want to wait for udevadm settle to run, but do want to guarantee that kpartx has run, then you might be left with what you have. Keep running kpartx until it succeeds. This is, of course, assuming that what's going on here is what I outlined above. But as long as /lib/udev/rules.d/66-kpartx.rules exists, udev should try to run kpartx in this case, and racing kpartx calls will occasionally cause this issue.

Does this look like it could be the issue to you?

Ahh thanks for the details. I wasn't aware of 66-kpartx.rules. In that case, your theory is indeed highly plausible.
In the end, we were able to drop the code that was hitting this entirely, so we can close this issue.

Thanks!