Silent stale output from Haxe compilation server cache after source edits
0 reputation · 02 Mar 2025, 17:58 UTC
The goal is to determine the correct invalidation policy for the Haxe compilation server's per-file module cache. When the server remains running across incremental builds, edited sources can produce stale output because cached typed modules are reused without any reported failure.
Freshness is currently keyed on filesystem modification times. Edits saved within timestamp granularity, or on filesystems with coarse or unreliable mtimes, may not invalidate the cache. The cache scope is also per-file identity rather than full compilation context, so changes to compiler defines, macro arguments, classpath order, or untracked files may not force recompilation. Behavior may vary across Haxe 4.x releases and platforms, and the server is intended for local iteration rather than reproducible CI builds.
Should invalidation move to content hashing, or remain mtime-based for speed? Should the cache key incorporate compiler defines, macro arguments, and classpath order? Is restarting the compilation server the only dependable way to discard stale modules?