Silent stale output from Haxe compilation server cache after source edits

Recommended approach

Keep mtime-based invalidation for local iteration, but treat a running compilation server as non-authoritative for correctness. Restart the server when you change compiler defines, macro inputs, classpath order, or when you suspect mtime granularity hid an edit. Do not adopt content hashing unless your installed Haxe 4.x build documents it; it is not a version-independent default.

Likely explanation

The compilation server keeps an in-memory per-file typed module cache across incremental builds. Freshness is keyed on source path and filesystem modification time. If an edit is saved within the same mtime tick, or on a filesystem with coarse or unreliable mtimes, the server can reuse a stale module and emit stale output without errors. Because the key is per-file identity rather than full compilation context, changes to -D defines, macro arguments, classpath order, or untracked dependencies may also fail to invalidate.

Confirmed facts

• Restarting the compilation server process discards the in-memory module cache and forces recompilation on the next build.
• The server targets local iteration, not reproducible CI builds; clean builds are appropriate for CI.
• Invalidation behavior varies across Haxe 4.x minor releases and platforms.

Steps for this case

1. Record haxe --version, operating system, and filesystem type.
2. If you edited sources and output looks stale, restart the compilation server and rebuild once to confirm the cache was the cause.
3. If you changed defines, macros, classpath order, or dependencies without editing sources, restart the server before rebuilding; mtime-only invalidation is not expected to catch those changes.
4. For CI or release builds, disable the compilation server and run clean Haxe builds.

Verification

haxe --version

Reproduce the stale-output scenario: edit a file, save within the same mtime tick, rebuild through the running server, restart the server, rebuild again, and compare output. Differing output confirms stale cached modules.

Missing diagnostic detail

Which Haxe 4.x minor release, platform, and filesystem are you using? This determines whether mtime granularity or server caching is the dominant factor and whether any content-hashing option exists in your build.

Assumptions and uncertainty

Content hashing would detect mtime-invisible edits but adds hashing I/O on every incremental check; support in your Haxe version is unverified. Broadening the cache key to defines, macros, and classpath order can cause over-invalidation and higher memory use. These are trade-offs, not confirmed defaults.