UserIndex misses file updates within the two-second lifecycle window
Upstream revision
- Commit:
ce046f26495c73f007790971869c94d58e0f6a20
- Upstream
user-index.ts SHA-256: a81b58266a6650cbd578c08c0e67f39dc533e150f9d406e29512acdeda7368d5
- Release-payload
user-index.ts SHA-256: c49af24ede618781f9e24185e939e2e6cb26b89413aa52a76799b15e04383397
Expected behavior
After start() completes, rewriting a file below the temporary USER directory should update user-index.json within two seconds.
Observed behavior
The exact upstream source and the pinned release source both miss the update. Their initial scans complete, but the rewritten marker does not appear in user-index.json before the two-second deadline.
The local compatibility implementation retains fs.watch and adds a periodic tree-signature check. That safety poll schedules a rebuild when the watcher misses a change.
Reproducer
Run the non-default reproducer from a LifeOS checkout:
bun LIFEOS/UPSTREAM_REPROS/UserIndexLifecycle.repro.ts \
--upstream-checkout /path/to/danielmiessler-LifeOS-at-ce046f2
The reproducer:
- Verifies the upstream commit and both source hashes.
- Creates separate temporary USER directories.
- Starts each UserIndex implementation.
- Rewrites
PROFILE.md after startup.
- Waits two seconds for the marker to appear in
user-index.json.
- Returns success only when both sources reproduce the pinned
upstream-defect classification.
Any hash or behavior change returns a nonzero status and requires review.
Proposed fix
Keep the recursive watcher as the fast path. Add a low-frequency tree-signature poll that schedules the existing debounced rebuild when the signature changes. Stop the poll in stop() and expose watcher or poll failures through module health.
Add a lifecycle test that writes after start() and requires the index to contain the new marker within the documented window. The test should use an isolated temporary USER directory and must not copy a private implementation into the installer.
UserIndex misses file updates within the two-second lifecycle window
Upstream revision
ce046f26495c73f007790971869c94d58e0f6a20user-index.tsSHA-256:a81b58266a6650cbd578c08c0e67f39dc533e150f9d406e29512acdeda7368d5user-index.tsSHA-256:c49af24ede618781f9e24185e939e2e6cb26b89413aa52a76799b15e04383397Expected behavior
After
start()completes, rewriting a file below the temporary USER directory should updateuser-index.jsonwithin two seconds.Observed behavior
The exact upstream source and the pinned release source both miss the update. Their initial scans complete, but the rewritten marker does not appear in
user-index.jsonbefore the two-second deadline.The local compatibility implementation retains
fs.watchand adds a periodic tree-signature check. That safety poll schedules a rebuild when the watcher misses a change.Reproducer
Run the non-default reproducer from a LifeOS checkout:
The reproducer:
PROFILE.mdafter startup.user-index.json.upstream-defectclassification.Any hash or behavior change returns a nonzero status and requires review.
Proposed fix
Keep the recursive watcher as the fast path. Add a low-frequency tree-signature poll that schedules the existing debounced rebuild when the signature changes. Stop the poll in
stop()and expose watcher or poll failures through module health.Add a lifecycle test that writes after
start()and requires the index to contain the new marker within the documented window. The test should use an isolated temporary USER directory and must not copy a private implementation into the installer.