Name the file a host failure was about (#716) - #718
Merged
Conversation
The Windows run in #714 reported cursor as `config is not parseable JSON: Unexpected end of JSON input`. That says a parse of an empty string happened. It does not say which file was parsed -- and the counter-check on that machine found valid, byte-identical JSON. Both can be true. This command reads `%USERPROFILE%\.cursor\mcp.json` and only that, while Cursor keeps configuration in more than one place, so the installer and the person checking it can each be right about a different file. Nothing in the output separates the two, which is why the reason is still unestablished on the issue while the outcome is not. Waiting for that machine's transcript would not have settled it either. The path was never recorded anywhere, so no transcript could contain it. That is the defect: a receipt that names the failure but not its subject sends the next reader to a file that is fine. All seven read and write failures across the JSON and TOML hosts now lead with the path. The wording moves with it -- `config is not parseable JSON: ...` becomes `<path> is not parseable JSON: ...` -- because a message that begins with the subject is one a reader can act on without knowing the command's internal layout. Three cases assert the path rather than the wording, driving the enumeration with an empty PATH and a scratch home so detection turns on the fixture rather than on whatever the developer has installed. Limit: only failures name their file; a successful wire still reports no path Limit: this makes the cursor question answerable on the next Windows run -- it does not answer it, and the outcome (failed) was never in doubt Ruled-out: add a path field to HostResult | the summary schema is pinned at v1 and detail is already the free-text field a human reads Blast: module Undo: easy Certainty: firm Record-Id: r-namefile716 Provenance: authored Verified: reverting the three message changes fails all 3 new cases; 10 cases pass across the three installer-hosts suites; npx tsc --noEmit clean; build:canonical then artifact:verify -> 310a0d2420e1bf4196581913d0fc1752ea8eee25510741c683d61d67897510e6 CommitLore-Version: 2.0.0
CommitLore — record lintTrailers: clean — 3 commits in Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
…fix-716-name-the-file-read # Conflicts: # dist/commitlore.mjs # installer/canonical-artifact.json
MongLong0214
added a commit
that referenced
this pull request
Aug 17, 2026
Merged as a merge commit rather than squashed, deliberately. #718 is stacked on this branch. A squash would put a new SHA on main and leave this branch's commits out of main's history, so GitHub would retarget #718 against a merge base further back — its diff would re-include this change, and dist/commitlore.mjs would conflict again (main's dist holds only this fix; #718's holds both). That is the conflict we just resolved by regenerating; the merge method would have recreated it. The branch is kept, not deleted: deleting a base branch closes the PR stacked above it and it cannot be reopened. Toward #716, not closing it. This fixes the first of two causes a real Windows run found. The second — hasCommand never consults PATHEXT, so .cmd shims are invisible, and spawnSync with shell:false cannot execute them — is unfixed and cannot be closed without another Windows run.
This was referenced Aug 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #717 (the temp-filename fix). Partially addresses #716; the observation is #714.
The Windows run reported
cursoras:That message says a parse of an empty string happened. It does not say which file was parsed — and the counter-check on that machine found valid, byte-identical JSON.
Both can be true. This command reads
%USERPROFILE%\.cursor\mcp.jsonand only that, while Cursor keeps configuration in more than one place. The installer and the person checking it can each be right about a different file, and nothing in the output separates them. That is why #716 records the cursor outcome as confirmed and its reason as not.Waiting for that machine's transcript would not have settled it. The path was never recorded anywhere, so no transcript could contain it. A receipt that names the failure but not its subject sends the next reader to a file that is fine.
Change
All seven read/write failure paths across the JSON and TOML hosts now lead with the path:
config is not parseable JSON: …<path> is not parseable JSON: …mcpServers is not an objectmcpServers in <path> is not an objectatomic config write failed: …<path> could not be written atomically: …could not read config: …<path> could not be read: …commitlore registration has no runnable command and argsthe commitlore registration in <path> has no runnable…No schema change:
commitlore_installer_hosts.v1keeps its fields, anddetailwas already the free-text field a human reads.Why now
A Windows agent is about to re-run this on the machine that produced #714. Without this, that run produces the same undecidable output and the cursor question stays open for another round trip.
Verification
Reverting the three message changes fails all 3 new cases. The tests assert the path, not the wording, and drive the real enumeration with an empty
PATHand a scratch home so detection turns on the fixture rather than on whatever the developer has installed.10 cases pass across the three
installer-hostssuites;tsc --noEmitclean;build:canonicalthenartifact:verify→310a0d2420e1bf4196581913d0fc1752ea8eee25510741c683d61d67897510e6.This makes the cursor question answerable on the next Windows run. It does not answer it, and it does not touch cause 2 (
hasCommand/PATHEXT/shell: false), which still needs that machine.