Description
History loading treats any syntactically valid JSON object as a CommitEntry without validating its fields. buildProfile() then assumes entry.message is a string and calls string methods on it.
A single schema-invalid but valid-JSON history row can therefore make suggestion/profile generation fail instead of being ignored like malformed JSON rows are.
Location
src/history/store.ts:83-99 — processHistoryLine()
src/history/store.ts:443-485 — buildProfile()
Relevant code
try {
entries.push(JSON.parse(line) as CommitEntry);
} catch {
corruptedLineIndexesFromEnd.push(lineIndexFromEnd);
}
...
for (const entry of entries) {
const lines = entry.message.split('\n');
const firstLine = lines[0];
totalLengths.push(firstLine.length);
}
The JSON parse check proves only syntax validity; it does not establish that message, diff, model, and provider have the expected types.
Steps to Reproduce
- Ensure a valid config and at least one normal history entry exist.
- Append a syntactically valid but schema-invalid row such as
{"timestamp":"2026-09-21T00:00:00Z","message":123,"diff":"","model":"x","provider":"openai"}.
- Run
commit-echo suggest or commit-echo history.
buildProfile() reaches entry.message.split('\n') and throws a TypeError.
Expected Behavior
History corruption handling should reject schema-invalid rows and continue using valid recent entries, with the same warning behavior used for malformed JSON.
Actual Behavior
Syntactically valid but structurally invalid rows are accepted and can crash profile construction.
Suggested Fix
Validate the decoded value with a runtime type guard before pushing it into entries. Treat invalid shapes as corrupted history rows and continue scanning.
Impact
One bad persistent history row can block the core suggestion/profile path until the user manually edits or repairs history.jsonl. This defeats the existing corruption-tolerance logic.
Reviewed against current main at 6c01ad0a853501e9617a3af0a5db3b515dd8ed53.
Description
History loading treats any syntactically valid JSON object as a
CommitEntrywithout validating its fields.buildProfile()then assumesentry.messageis a string and calls string methods on it.A single schema-invalid but valid-JSON history row can therefore make suggestion/profile generation fail instead of being ignored like malformed JSON rows are.
Location
src/history/store.ts:83-99—processHistoryLine()src/history/store.ts:443-485—buildProfile()Relevant code
The JSON parse check proves only syntax validity; it does not establish that
message,diff,model, andproviderhave the expected types.Steps to Reproduce
{"timestamp":"2026-09-21T00:00:00Z","message":123,"diff":"","model":"x","provider":"openai"}.commit-echo suggestorcommit-echo history.buildProfile()reachesentry.message.split('\n')and throws a TypeError.Expected Behavior
History corruption handling should reject schema-invalid rows and continue using valid recent entries, with the same warning behavior used for malformed JSON.
Actual Behavior
Syntactically valid but structurally invalid rows are accepted and can crash profile construction.
Suggested Fix
Validate the decoded value with a runtime type guard before pushing it into
entries. Treat invalid shapes as corrupted history rows and continue scanning.Impact
One bad persistent history row can block the core suggestion/profile path until the user manually edits or repairs
history.jsonl. This defeats the existing corruption-tolerance logic.Reviewed against current
mainat6c01ad0a853501e9617a3af0a5db3b515dd8ed53.