Yicong-Huang opened a new issue, #7075:
URL: https://github.com/apache/texera/issues/7075
### What happened?
The dirty-source fast filter treats "source mtime **equal** to the build
stamp's mtime" as clean, so an edit that lands in the same filesystem
timestamp
tick as the stamp write is never rebuilt. `bin/local-dev.sh auto` reports
`everything up-to-date` and bounces nothing; the TUI's `SRC` column shows no
`*`.
Both implementations have it, and the shell one is the consequential half —
it's what gates the rebuild:
| Where | Code | Miss |
| --- | --- | --- |
| `bin/local-dev/main.sh` `svc_src_changed` | `find "${dirs[@]}" … -newer
"$stamp"` | `find -newer` is *strictly* newer |
| `bin/local-dev/tui.py` `_newest_mtime_after` | `if f.stat().st_mtime >
stamp_mtime` | strict `>` |
The window is one timestamp tick wide, which sounds negligible but isn't: the
stamp is written at the end of a build, and the natural next action is to
edit
the file you were just building. How wide the tick is depends on the
filesystem and kernel clock granularity, not on how fast you type.
Reproduced deterministically by giving a source the same mtime as the stamp:
```
$ D=$(mktemp -d); mkdir -p $D/src; : > $D/stamp; : > $D/src/A.scala
$ touch -r $D/stamp $D/src/A.scala # identical mtimes
$ find $D/src -name '*.scala' -newer $D/stamp -print
# <- empty: A.scala is invisible
```
On the Python side the existing test `test_is_dirty_after_seed_then_edit`
already fails on any filesystem whose granularity is coarser than two
consecutive `write_text` calls — it does exactly stamp-then-edit:
```
stamp mtime: 1785362843.238977
src mtime: 1785362843.238977 <- identical, no typing involved
newest_after: False -> is_dirty() False, though content changed
```
macOS (APFS, ns resolution) and the GitHub `ubuntu-latest` runners happen not
to hit it, so CI on `main` is green and this reads as a local-only oddity.
The slow path underneath is correct — it compares content hashes and even
refreshes the stamp's mtime when only mtimes moved. The bug is purely that
the
fast filter can decide "definitely clean" without ever consulting it.
```
Before: build -> edit within the same tick -> auto: "everything up-to-date"
After: build -> edit within the same tick -> hash compared -> rebuilt
```
Widening the filter to include equality is self-healing rather than a
permanent slowdown: the first tick after a build takes the hash path once,
finds the content unchanged, and `os.utime`/`touch` bumps the stamp past the
sources, so subsequent ticks are cheap again.
### How to reproduce?
```sh
# shell path (gates the rebuild)
bin/local-dev.sh up # writes the build stamps
touch -r /tmp/texera-local-dev/build-stamps/*/config-service \
config-service/src/main/scala/<some file>.scala # same mtime as
the stamp
# edit that file for real, keeping the mtime equal, then:
bin/local-dev.sh auto # "everything up-to-date" — wrong
# python path
python -m pytest
bin/local-dev/tests/test_local_dev_tui.py::test_is_dirty_after_seed_then_edit
# fails wherever the filesystem's timestamp granularity is coarser than the
# gap between the test's two writes
```
### Version/Branch
1.3.0-incubating-SNAPSHOT (main)
### Relevant log output
```shell
$ bin/local-dev.sh auto
✓ everything up-to-date — nothing to bounce
$ python -m pytest bin/local-dev/tests/ -q
FAILED
bin/local-dev/tests/test_local_dev_tui.py::test_is_dirty_after_seed_then_edit
1 failed, 42 passed
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
