The GitHub Actions job "Required Checks" on texera.git/fix/local-dev-dirty-mtime-tick has succeeded. Run started by GitHub user Yicong-Huang (triggered by Yicong-Huang).
Head commit for run: 2071810dab749f15cb8be48cf499a9d5906c292e / Yicong Huang <[email protected]> fix(local-dev): rebuild a source edited in the stamp's timestamp tick The dirty-source fast filter treated "source mtime equal to the build stamp's" as clean, so an edit landing in the same filesystem timestamp tick as the stamp write was never rebuilt: `auto` reported `everything up-to-date` and bounced nothing. The window is one tick wide, but the stamp is written at the end of a build and the natural next action is editing the file you were just building, so it is hit in normal use — how wide the tick is depends on the filesystem and kernel clock granularity, not on how fast anyone types. Both implementations had it. `svc_src_changed` used `find -newer "$stamp"`, where `-newer` is strictly newer; `tui.py`'s `_newest_mtime_after` used a strict `>`. The shell side is the consequential half — it is what gates the rebuild, while tui.py only colours the SRC column. It now compares against a throwaway marker one second behind the stamp, because `find` has no portable "not older than". The stamp itself keeps its real mtime, so the mtime refresh at the end of the slow path still converges. tui.py can say what it means, so it uses `>=`. Both directions stay conservative rather than wrong: widening the filter only enlarges the candidate set, and the content hash underneath — which was always correct — makes the actual decision. It also self-heals, because the first tick after a build takes the hash path once, finds the content unchanged, and bumps the stamp past the sources. This also fixes `test_is_dirty_after_seed_then_edit`, which had been failing on any filesystem whose granularity is coarser than its two consecutive writes; the new test forces the colliding mtime with `os.utime` so it no longer depends on the platform. Closes #7075 Report URL: https://github.com/apache/texera/actions/runs/30498240826 With regards, GitHub Actions via GitBox
