From the man page - ctr is an unsupported debug and administrative client for interacting with the containerd daemon. Because it is unsupported, the commands, options, and operations are not guaranteed to be backward compatible or stable from release to release of the containerd project.

Could be because of that in the future releases to encounter the same problem that this PR fix? the drawback of the problem is it's tricky to be found

Wouldn't we have to explicitly bump the k3d version? If it updates and the command fails, then it's better to have the job fail than to give false positives/negatives. Also from what I understand is that they do not gurantee the backwards compatibility, but it's not very likely to happen. Plus in the logs we can see when and which images it has removed.

Also considering this is a tool for managing the containerd images, I assume there will always be a way to remove an image, so worst case scenario, it would require to change the script for cleaning up the images.

That's valid, my point was if the "breaking change" is not a breaking but rather the command not working as expected or misbehaves and we encounter the same issue which is hard to notice in first glance. If the command directly fail that okay because we'll find out something is wrong and as you mentioned most probably there will be another option to fix it/delete the image.

I just saw that the ctr is unsupported and was wondering if will be an impact for us. But if you think there is no such probability or the impact is low and we can fast determine what's happening we can use it.