An unreadable tracked code file permanently bricks changed_symbols and review_diff — the I034 brick through a sixth door #147

New issue

Closed

opened 2026-09-05 12:54:05 +02:00 by buildagent · 0 comments

buildagent commented

2026-09-05 12:54:05 +02:00

Member

Found by a production-readiness review. This is the I034 freshness-barrier brick again, through a door I034 did not close.

The path

EACCES / EISDIR / a Windows file lock on a tracked code file → ContentEligibility::Unknown → Freshness::STALE (crates/mcp-server/src/server.rs:5194) → the freshness barrier exhausts → changed_symbols and review_diff return index_updating with "retry in a moment", forever.

The file will never become readable by waiting. index_stale is permanent for a file that cannot be read, which is the identical mechanism I034 fixed for never-indexable files under dist//bin//obj/ — repaired there with a walker-PROVED not_indexed. The proof is per-cause, so a new cause reopens the brick.

The test that should have caught it

server.rs:21296 asserts only that such a file classifies as Unknown rather than Refused — the correct half — and grades nothing downstream. It never asserts what the tools then return. The code comment two lines above even names "a fifth door" it closed, which is what makes this the sixth.

Ask

An unreadable tracked file must resolve to a terminal, disclosed state — not to pending/index_updating. The user must be told which file and that waiting will not help.
The test must grade the tool output, not the intermediate classification. That is the general lesson: this brick has now appeared six times because each fix graded the classifier rather than the payload.
Consider whether the barrier should ever be able to return index_updating without a bounded horizon. A retry instruction with no reachable success condition is the shape of every one of these six.

I034 (freshness barrier), #140, #124 — same family.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

Found by a production-readiness review. This is the I034 freshness-barrier brick again, through a door I034 did not close. ## The path EACCES / EISDIR / a Windows file lock on a **tracked** code file → `ContentEligibility::Unknown` → `Freshness::STALE` (`crates/mcp-server/src/server.rs:5194`) → the freshness barrier exhausts → `changed_symbols` and `review_diff` return `index_updating` with *"retry in a moment"*, **forever**. The file will never become readable by waiting. `index_stale` is permanent for a file that cannot be read, which is the identical mechanism I034 fixed for never-indexable files under `dist/`/`bin/`/`obj/` — repaired there with a walker-PROVED `not_indexed`. The proof is per-cause, so a new cause reopens the brick. ## The test that should have caught it `server.rs:21296` asserts only that such a file classifies as `Unknown` rather than `Refused` — the correct half — **and grades nothing downstream**. It never asserts what the tools then return. The code comment two lines above even names "a fifth door" it closed, which is what makes this the sixth. ## Ask 1. An unreadable tracked file must resolve to a terminal, disclosed state — not to `pending`/`index_updating`. The user must be told **which file** and **that waiting will not help**. 2. The test must grade the tool output, not the intermediate classification. That is the general lesson: this brick has now appeared six times because each fix graded the classifier rather than the payload. 3. Consider whether the barrier should ever be able to return `index_updating` without a bounded horizon. A retry instruction with no reachable success condition is the shape of every one of these six. ## Related - I034 (freshness barrier), #140, #124 — same family. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent referenced this issue

2026-09-05 12:54:34 +02:00

code-index doctor is blind to staleness, watcher health and resolve state, and check_disk_free only fires at literally zero bytes #150

buildagent referenced this issue

2026-09-05 17:02:37 +02:00

A permanently malformed lockfile is indistinguishable from a torn mid-write read, so a corrupt payload reads as "no daemon" forever #157