Repository navigation
Dockerfile with trailing whitespace and no final newline reported as parse_partial #1746
Description
Summary
A Dockerfile whose final instruction ends with trailing whitespace and no terminating newline is
reported as parse_partial, with the error range pointing at that last line. The instruction itself is
valid and Docker builds it fine.
Adding either a newline or removing the trailing space makes the file parse cleanly, so the trigger is
specifically <instruction><space><EOF> with no line terminator.
Minimal reproduction
Two files in an otherwise empty directory (plus any source file so the pipeline has something to index):
Dockerfile — note the single trailing space after ], and no trailing newline:
FROM scratch
ENTRYPOINT ["a"]·
Generate it exactly (· above is a literal space):
printf 'FROM scratch\nENTRYPOINT ["a"] ' > Dockerfile
printf 'public class A { public int B() => 1; }\n' > A.csThen:
codebase-memory-mcp cli index_repository --repo_path=. --mode=fast --name=reproExpected
parse_partial count: 0
Actual
parse_partial count: 1
FLAGGED: Dockerfile -> 2-2
Controls that isolate the trigger
Same two-line Dockerfile, only the final bytes differ. Each indexed as its own subdirectory in one run:
| Final bytes of file | Last byte | Result |
|---|---|---|
ENTRYPOINT ["a"] (space, no newline) |
0x20 |
flagged 2-2 |
ENTRYPOINT ["a"] \n (space, then newline) |
0x0a |
clean |
ENTRYPOINT ["a"] (no space, no newline) |
0x5d |
clean |
So neither "missing trailing newline" nor "trailing whitespace" alone is enough — it takes both together.
The same pattern shows up in real-world files: in a repo of mine, the two Dockerfiles ending in ] + EOF
are both flagged at their final line, while a third Dockerfile that also lacks a trailing newline but has no
trailing space is not flagged. The originally-flagged files use CRLF line endings and the synthetic repro
above uses LF, so this appears independent of line-ending style.
Environment
- codebase-memory-mcp 0.10.8 (Windows x64 build)
- Windows 11 Pro 10.0.22631
- Reproduced via both the MCP
index_repositorytool and thecli index_repositoryone-shot path
Notes
- Likely upstream in the tree-sitter Dockerfile grammar's handling of a final unterminated line rather than
in this project's own code — feel free to reclassify or forward. - Low severity: the affected node is an
ENTRYPOINTline, so little of graph value is lost. Filing it mainly
because it producesparse_partialnoise that makes the coverage report look worse than it is, and because
trailing whitespace at EOF is common in checked-in Dockerfiles.
Activity
fix(extraction): treat trailing blanks at EOF as an absent newline, n…
fix(extraction): treat trailing blanks at EOF as an absent newline, n…
fix(extraction): treat trailing blanks at EOF as an absent newline, n…
fix(extraction): treat trailing blanks at EOF as an absent newline, n…
DeusData commentedon Aug 29, 2026
Landed on main in
ef8a8dc3(PR #1853, "fix: ignore trailing Dockerfile whitespace at EOF").Leaving this open pending your confirmation rather than closing it on my own reading. The PR references this issue rather than declaring it fixed, and your report names two conditions — trailing whitespace and no final newline — where the fix is scoped to trailing whitespace at EOF. Those may well be the same case in practice, but I would rather you confirm against your actual Dockerfile than have me assume it and close a bug that still reproduces.
If it is fixed for you, say so and I will close it citing the SHA. If the no-final-newline variant still misbehaves, that is worth knowing separately.
fix(extraction): treat trailing blanks at EOF as an absent newline, n…
Merge pull request #1773 from rarepops/fix/dockerfile-trailing-blank-…
DeusData commentedon Sep 3, 2026
Follow-up fix on
main:572725e6, merged as6cca7688via #1773. Thanks to @rarepops.#1853(27 August) fixed the reported case but allowed only' 'and'\t'as trailing blanks, so\v,\fand a trailing\rstill produced a phantomparse_partial. The suppression now usescbm_is_blank_not_newline()— every blank except newline — while keeping#1853's tightening that only a MISSING newline token is ever suppressed.Worth recording for the history: #1773 was opened on 20 August, seven days before #1853, and already argued against the hand-picked subset that #1853 then shipped:
The contributor was right first, and the narrower version landed only because their PR had not been read.
Covered by six fixtures (space, tab, vertical tab, form feed, blank run, CR) plus two guards asserting that a genuine mid-file failure and a width-bearing loss at EOF are still flagged.
fix(extraction): parse every file as if its last line were terminated (…
fix(extraction): parse every file as if its last line were terminated (…
fix(extraction): parse every file as if its last line were terminated (…
fix(extraction): parse every file as if its last line were terminated (…