Version
v0.10.7
Platform
Linux (x64)
Install channel
Built from source
Binary variant
standard
What happened, and what did you expect?
Files with parse_partial ranges (and modified files generally) can have stale AST line coordinates after the file is edited on disk without re-indexing.
get_code_snippet reads and slices source lines from the live file on disk using the coordinates stored at index time. When the file has shifted due to edits, it returns shifted/corrupted source text or an entirely different function's body for the requested symbol.
search_code runs grep against the live file on disk (obtaining current line numbers) but maps matches to symbols using stored (stale) [start_line, end_line] node ranges, causing grep hits to be misattributed to adjacent functions, and in MODE_FULL returning drifted source lines.
Expected behavior:
When file metadata changes on disk (freshness != "metadata_match"), tools should detect drift and avoid returning corrupted source slices or misattributed symbols.
Reproduction
- Initial indexed state:
check_index_coverage on src/mcp/mcp.c before edit:
{
"path": "src/mcp/mcp.c",
"status": "partial",
"freshness": "metadata_match"
}
Indexed coordinates for maybe_auto_index: 11769–11819.
-
Modification on disk:
Insert 50 comment lines immediately above maybe_auto_index in src/mcp/mcp.c. The function's true location on disk moves from 11769–11819 to 11819–11869. No index_repository or re-index is performed.
-
Query:
Call get_code_snippet for maybe_auto_index.
-
Actual result:
Returned:
start_line: 11769
end_line: 11819
The returned source field contained the 50 newly inserted comment lines plus the function signature, rather than the function's actual body at its live location. In other queries, it returned the body of dispatch_tool instead.
Confirmations
Version
v0.10.7
Platform
Linux (x64)
Install channel
Built from source
Binary variant
standard
What happened, and what did you expect?
Files with
parse_partialranges (and modified files generally) can have stale AST line coordinates after the file is edited on disk without re-indexing.get_code_snippetreads and slices source lines from the live file on disk using the coordinates stored at index time. When the file has shifted due to edits, it returns shifted/corrupted source text or an entirely different function's body for the requested symbol.search_coderunsgrepagainst the live file on disk (obtaining current line numbers) but maps matches to symbols using stored (stale)[start_line, end_line]node ranges, causing grep hits to be misattributed to adjacent functions, and inMODE_FULLreturning drifted source lines.Expected behavior:
When file metadata changes on disk (
freshness != "metadata_match"), tools should detect drift and avoid returning corrupted source slices or misattributed symbols.Reproduction
check_index_coverageonsrc/mcp/mcp.cbefore edit:{ "path": "src/mcp/mcp.c", "status": "partial", "freshness": "metadata_match" }Indexed coordinates for
maybe_auto_index:11769–11819.Modification on disk:
Insert 50 comment lines immediately above
maybe_auto_indexinsrc/mcp/mcp.c. The function's true location on disk moves from11769–11819to11819–11869. Noindex_repositoryor re-index is performed.Query:
Call
get_code_snippetformaybe_auto_index.Actual result:
Returned:
The returned
sourcefield contained the 50 newly inserted comment lines plus the function signature, rather than the function's actual body at its live location. In other queries, it returned the body ofdispatch_toolinstead.Confirmations