Codeac 3.0 Cache Invalidation – Do External Library Changes Trigger a Re‑Analysis?

Cache Invalidation in Codeac 3.0

Codeac’s incremental analysis relies on a cache that is refreshed only when a source file’s last‑modified timestamp changes. The documentation for 3.0, however, does not clarify whether a change in a transitive dependency or a build configuration should cause the cache to be invalidated. This omission creates uncertainty for projects that rely on library updates or dynamic build scripts.

The current configuration offers no flag to force a full cache purge after every rebuild; users must manually delete the cache directory. Additionally, the log output reports a generic “Cache hit” message without indicating whether the hit was based on a timestamp or an internal content hash, making it hard to determine if stale results are being served.

Given the lack of explicit guidance, the unresolved question is whether Codeac 3.0 will automatically detect changes in external libraries or build settings and invalidate the relevant cache entries, or if manual intervention is required. This uncertainty affects build reliability and performance tuning.

Questions:
1. Does Codeac 3.0 invalidate its cache when a transitive dependency’s artifact changes, even if the source files remain untouched?
2. Is there an undocumented flag or environment variable that can trigger automatic cache invalidation on dependency updates?
3. What is the internal mechanism that determines a “Cache hit” – a timestamp comparison or a content hash, and can it be configured?