dd.watch.digest and trivy aggregation

[larueli]

Hello,

Thank you a lot for your work, I am testing the 1.4.0 release.

If I understand correctly, when dd.watch.digest: "true" is set on a container, a call is made regularly to the registry to check if the image is updated. This can sometimes lead to 429 (too much requests).

If I have multiple containers with the same exact ref (for instance : docker.io/library/postgres:18.3) across multiple agents (and on the controller itself) with the dd.watch.digest: "true", is the image fetched only once (and hash compared with all the running containers), or is it pulled and compared for every container instance ? Is there any aggregation of any kind ?

For trivy scanning, is there a cache to store the score with the hash of the image to avoid pulling it for every update if the image to fetch is already scanned ? Is the trivy scanning done only on the controller or is it repeated on every agent ?

Aggregating the calls on the controller and caching the results could be a nice to have (if it doesn't exist already), I have for instance 20+ postgres containers running with docker.io/library/postgres:18.3 across my agents, it could be checked only once with the registry and then compared with all my instances. For now I will set this label dd.watch.digest: "true" on a few containers only.

[scttbnsn]

Hi @larueli, thanks for the detailed questions — and for testing v1.4.0!

Digest watching — per-container, no dedup:

You're correct. When dd.watch.digest=true is set, the watcher makes a registry manifest HEAD request on each poll cycle per container. If you have 20 postgres:18.3 containers across multiple agents, each agent independently checks each of its containers — even though the remote digest is identical. There's currently no within-agent or cross-agent deduplication for digest checks.

Trivy scanning — controller-side, with digest-based caching:

Trivy scans run on the controller (not on agents). The security scheduler has a digest-based scan cache — if two containers share the same image digest, the second one gets the cached result instead of re-scanning. This cache persists across scan cycles (it's an in-memory LRU cache that invalidates when the Trivy database updates). So for your 20 identical postgres containers, only the first one triggers an actual scan; the rest hit the cache.

What's not deduplicated:

• Registry digest checks (each container polls independently, as described above)
• Cross-agent registry calls (each agent polls its own containers)

Your suggestion about registry-level dedup is valid — for large multi-agent deployments, caching manifest digests by image reference within a poll cycle would avoid redundant registry calls. That optimization isn't implemented yet but would naturally fit alongside the multi-agent aggregated dashboard work planned for v1.8.0 (Phase 7.2). I've added it to the roadmap.

For now, limiting dd.watch.digest=true to a representative subset of containers per image is a good workaround. You can also reduce pressure with a longer DD_WATCHER_{name}_CRON interval.