ingitdb / ingitdb-cli / 25815899508

96%

Build Type

push

github

Committed by inGitDB Dev

Commit Message

fix(insert): harden batch rollback (MapOfRecords, ordering, git errors)

Addresses findings #2, #3, #4 + two cheap suggestions from the final
batch-insert review.

#2: batch mode now refuses MapOfRecords collections at the pre-flight
stage with a clear diagnostic. The previous behavior would have
silently shared a file path across all batch records, causing the
rollback path to delete pre-existing records on failure. Future work
can add proper MapOfRecords batch support (via SetMulti or buffered
writes); for MVP the explicit rejection is correct.

#3: KEPT the original ordering (append AFTER tx.Insert) and added a
comment explaining why. The plan suggested reordering on the theory
that rollback tolerates non-existent paths, but the existing
TestInsertBatch_JSONL_CollisionWithExistingRecord proves the suggested
ordering is unsafe for the current dalgo2fsingitdb backend: tx.Insert
performs the collision check BEFORE writing, so appending the path
pre-insert causes rollback to remove a pre-existing file at the
same path (i.e. the colliding record), destroying real data. The
reorder may be revisited if the backend changes to write-then-check.

#4: isTracked now distinguishes 'git ls-files --error-unmatch' exit
code 1 (not tracked) from other failures (transient .git/index.lock,
command not found, network errors on remote repos). Other failures
default to 'treat as tracked' — git checkout HEAD -- on an untracked
file is a benign no-op, but failing to restore a tracked file
destroys data.

Suggestions: ParseBatchYAMLStream's docNo increment moved to the top
of the loop body for cleaner error indexing. rollbackBatchWrites
groups all tracked paths into a single 'git checkout HEAD -- p1 p2 ...'
invocation instead of one process per file — meaningful on large
batches; gitCheckoutPath renamed to gitCheckoutPaths and takes a
slice.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Coverage Stats

22 of 50 new or added lines in 2 files covered. (44.0%)

74 existing lines in 4 files now uncovered.

8062 of 10228 relevant lines covered (78.82%)

0.93 hits per line