ADFA-4128: absorb a mid-rebuild save only when its mtime proves it predates the rebuild

A filesystem that truncates mtimes to whole seconds can stamp a save made just
after a proxy app rebuild started with an mtime just before it. The echo split
then folded it into the absorbed set and onBaselineReset dropped it: the edit
never built and nothing said so.

An mtime on a whole-second boundary is now taken as truncated and must predate
the rebuild start by 2 s (the FAT step) to absorb. A flat margin on every mtime
would instead strand a genuinely pre-start save on every filesystem, because the
watcher's debounce (150 ms quiet, 1 s cap) puts such a save's mtime within a
second of the start; four of the existing F4 echo tests go red under it. A file
the rebuild already holds keeps the exact cutoff, since its arrival is the echo
the split exists to absorb.

Review thread: #1718 (comment)

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XkGof8cLt23LkxZ8MKzin2

Author: fryanpan

quickbuild/core/src/main/java/org/appdevforall/cotg/quickbuild/domain/reload/LiveReloadOrchestrator.kt

@@ -493,6 +493,21 @@ class LiveReloadOrchestrator(
 	 * start, files with no readable mtime (nothing proves they predate the read), removals (no
 	 * mtime left to date them), and [ChangedFiles.Unknown].
 	 *
+	 * A filesystem may truncate mtimes to whole seconds (ext4 without extended timestamps,
+	 * two seconds on FAT), so a save landing just after the start can report an mtime just
+	 * before it. An mtime on a whole-second boundary is taken as truncated, and a file with
+	 * one is absorbed only when it predates the start by [MTIME_GRANULARITY_MARGIN_MILLIS]:
+	 * on a coarse filesystem that errs toward one extra build rather than a silently dropped
+	 * edit, and on a precise one it misfires on the one save in a thousand that lands on an
+	 * exact second, at the same cost. Applying the margin to every mtime instead would strand
+	 * a genuinely pre-start save on every filesystem: the watcher's debounce (150 ms quiet,
+	 * 1 s cap) puts such a save's mtime within a second of the start.
+	 *
+	 * A file the rebuild already holds keeps the exact cutoff even when truncated: its
+	 * arrival is the echo of the save the rebuild is absorbing, and stranding that echo is
+	 * the spurious invalidation this split exists to prevent. The residual is a re-edit of a
+	 * held file within the margin after the start on a coarse filesystem, which absorbs.
+	 *
 	 * The absorbed part joins [awaitingAbsorption] via [ChangedFiles.plus], NOT
 	 * [unionPendingLocked]: this rebuild IS the Gradle build these files would demand, so
 	 * latching a sticky verdict from them would re-report the invalidation it is resolving.
@@ -506,7 +521,16 @@ class LiveReloadOrchestrator(
 		if (changes !is ChangedFiles.Known) return changes
 		val absorbed =
 			changes.files.filterTo(mutableSetOf()) { file ->
-				fileLastModified(file) in 1..absorptionStartedAtMillis
+				val mtime = fileLastModified(file)
+				val heldAlready = held !is ChangedFiles.Known || file in held.files
+				val truncated = mtime % 1_000L == 0L
+				val cutoff =
+					if (heldAlready || !truncated) {
+						absorptionStartedAtMillis
+					} else {
+						absorptionStartedAtMillis - MTIME_GRANULARITY_MARGIN_MILLIS
+					}
+				mtime in 1..cutoff
 			}
 		if (absorbed.isEmpty()) return changes
 		awaitingAbsorption = held + ChangedFiles.Known(absorbed)
@@ -863,6 +887,12 @@ class LiveReloadOrchestrator(
 		 * full Gradle build.
 		 */
 		const val ESCALATE_AFTER_IDENTICAL_FAILURES = 2
+
+		/**
+		 * Coarsest mtime granularity a project tree is expected to sit on: FAT stamps mtimes in
+		 * 2 s steps, ext4 without extended timestamps in 1 s. See [absorbEchoesLocked].
+		 */
+		const val MTIME_GRANULARITY_MARGIN_MILLIS = 2_000L
 	}
 }
 

quickbuild/core/src/test/java/org/appdevforall/cotg/quickbuild/domain/reload/LiveReloadOrchestratorTest.kt

@@ -726,6 +726,35 @@ class LiveReloadOrchestratorTest {
 			assertThat(executor.requests).isEmpty()
 		}
 
+	@Test
+	fun `a mid-rebuild edit the rebuild does not hold stays pending when its coarse mtime lands inside the granularity margin`() =
+		runTest {
+			// A filesystem with 1 s mtimes stamps a save made just after the rebuild started
+			// with an mtime a second before it, on a whole-second boundary. Absorbing on that
+			// mtime would lose the edit: onBaselineReset drops the absorbed set and nothing
+			// builds it. The precise 9_900 echoes in the tests above sit inside the same
+			// margin and must still absorb - the margin is for truncated mtimes only.
+			val executor = GatedExecutor()
+			val orchestrator =
+				LiveReloadOrchestrator(
+					executor,
+					ChangeClassifier(),
+					backgroundScope,
+					wallClock = { 10_000L },
+					fileLastModified = { file -> if (file.path == srcA) 9_000L else 0L },
+				) {}
+
+			orchestrator.onFilesChanged(known("app/src/main/AndroidManifest.xml"))
+			runCurrent()
+			orchestrator.onProxyAppRebuildStarted()
+			orchestrator.onFilesChanged(known(srcA))
+			orchestrator.onBaselineReset()
+			runCurrent()
+
+			assertThat(executor.requests).hasSize(1)
+			assertThat(executor.requests[0].changes).isEqualTo(known(srcA))
+		}
+
 	@Test
 	fun `a mid-rebuild file with no readable mtime stays pending - nothing proves it predates the read`() =
 		runTest {