Why only a few images are tagged as "no change" during a scan

[wsw70]

During the last scan (similarly to previous ones), only a few images were tagged as "no change". In this case, only 3 of about 60 images total.

Why is it so?

[Will-Luck]

So "No Change" (renamed to "Image Identical" in the next release) isn't actually the normal "everything's fine" result. It only fires in a pretty specific scenario:

1. The registry check found what looked like a newer tag or digest
2. The container has an auto policy, so Sentinel went ahead and pulled the new image
3. After pulling, it compared the old and new image IDs and found they were actually identical

Basically a safety net - it catches cases where a tag like latest has a new manifest but the actual image layers haven't changed, and skips the restart so you don't get unnecessary downtime.

The other ~57 containers are just genuinely up to date. The registry confirmed there's nothing new, so they don't get a history entry. If I wrote "all good" for every container every scan cycle the history page would be completely buried!

In v2.10.1 I'm adding a scan summary row that shows the full breakdown after each scan: "28 checked, 28 up to date, 0 updated..." etc. Should give you the visibility you're after without the clutter.

[wsw70]

Ahhh, this is a very clever check then! Thanks a lot for thinking about that.
This is a mistake of the author of the image then (and I will file a bug).
This said, there is nothing I can do as a user, and after your check we are back to the "everything is ok" realm so thanks for the extra information!

[wsw70]

Though, when I had a look at the mosquitto (mqtt) image, I am not sure what changed to trigger a download:

This happens on each scan

[Will-Luck]

Good catch on the mosquitto pattern. You're right that it shouldn't be triggering a download every scan if nothing actually changed.

I traced through the code and found a bug in the digest equivalence cache. When the image ID guard fires (pull completed, image IDs match, skip the restart), it's supposed to cache the digest pair so the next scan recognises it and skips entirely. But the caching code was doing:

localDigest := ImageDigest(oldImage)   // repo digest
newDigest := ImageDigest(pullImage)     // repo digest
CacheDigestEquivalence(localDigest, newDigest)

For mutable tags like :latest, oldImage and pullImage are the same reference. After pulling, both resolve to the same digest. So the cache stores sha256:AAA|sha256:AAA, which is completely useless.

The next scan compares ImageDigest (repo/platform digest) against DistributionDigest (registry manifest digest). For multi-arch images, or images where the registry rebuilds the manifest without changing content, these are different digest types that will never match naturally. The cache was supposed to bridge that gap but never did.

Fixed by caching ImageDigest(pullImage) | DistributionDigest(pullImage) instead. That's the exact pair the next scan compares, so the equivalence cache actually works. After one pull confirms the image is identical, subsequent scans will skip it until the registry genuinely changes the image content.

Fix is in 4ef71ba on dev, will be in the next release.