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

Question

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?

Tasadduq Burney · Answer

Direct Answer
Based on typical static-analysis tool behavior and the 3.0 documentation gap you described, Codeac 3.0 does not automatically invalidate its cache when transitive dependencies or build configurations change if the source file timestamps remain unchanged. The cache key appears to be derived from source-file modification times (or a hash of their contents) only. There is no documented flag, environment variable, or configuration option to force invalidation on dependency updates.

Likely Explanation vs. Confirmed Facts

AspectLikely Behavior (Inference)Confirmed by Docs/Source

Transitive dependency changeNo automatic invalidationNot documented
    Build script/config changeNo automatic invalidationNot documented
    Cache-hit determinationTimestamp or content hash of source files onlyLog shows generic “Cache hit”
    Force-full-purge flagNone existsNot documented

Practical Workaround Steps

Delete the cache directory before a build that follows a dependency upgrade:
    rm -rf .codeac/cache   # or the path shown in your config
  
  Add a cache-busting step to your CI pipeline after dependency resolution:
    # Example for Gradle/Maven projects
./gradlew dependencies --write-locks  # or mvn dependency:resolve
rm -rf .codeac/cache
codeac analyze
  
  Verify cache behavior by running two analyses back-to-back after a dependency change:
    
      Run analysis → note “Cache hit” count.
      Delete cache → run again → compare “Cache miss” count and findings.

One Diagnostic Detail That Would Change the Recommendation
If you can confirm whether Codeac 3.0 reads a lockfile (e.g., gradle.lockfile, pom.xml checksums, package-lock.json) into its cache key, the answer shifts from “manual purge required” to “automatic on lockfile change.” Please run a test: change only a dependency version in the lockfile (without touching source), then run analysis and check if the log shows “Cache miss” for affected files.

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

Cache Invalidation in Codeac 3.0

1 answer

Direct Answer

Likely Explanation vs. Confirmed Facts

Practical Workaround Steps

One Diagnostic Detail That Would Change the Recommendation

Your perspective belongs here.

0 question comments

Aspect	Likely Behavior (Inference)	Confirmed by Docs/Source
Transitive dependency change	No automatic invalidation	Not documented
Build script/config change	No automatic invalidation	Not documented
Cache-hit determination	Timestamp or content hash of source files only	Log shows generic “Cache hit”
Force-full-purge flag	None exists	Not documented