Lore version
lore 0.9.0
Installation method
Built from source
Operating system / architecture
Cross-platform (reproduced on macOS arm64, Linux x86_64, and Windows x86_64)
Steps to reproduce
Using the C API against a fresh local/offline repository:
static void on_commit(const lore_event_t *event, uint64_t context)
{
if (event->tag == LORE_EVENT_COMPLETE && event->complete.status == 0) {
puts("commit reported success");
fflush(stdout);
_Exit(9); /* no release, shutdown, or repository flush */
}
}
lore_event_callback_config_t callback = {
.user_context = 0,
.func = on_commit,
};
/* Create a new local/offline repository and stage a file. */
lore_file_stage(&globals, &stage_args, callback);
lore_revision_commit(&globals, &commit_args, callback);
- Run that child process against a fresh repository
- In the parent process, reopen the repository and query revision history
- Compare with a control run where the callback calls
lore_repository_flush(&globals, &flush_args, callback) before _Exit
Expected vs actual behavior
Expected: Either successful commit completion is a durability boundary, or the public API documentation explicitly states that callers must complete lore_repository_flush before acknowledging a save.
Actual: Commit completion schedules, but does not await, persistence. A process termination at the successful commit callback can lose the revision that was just reported as complete.
Component
Client (CLI)
Server context
local/offline mode only
Regression?
This reproduced in 0.8.5 at approximately 20% frequency and still reproduces in 0.9.0.
Relevant logs or output
The 0.9.0 implementation dispatches successful commit completion via callback and then spawns the repository flush in the background. Only the separate `lore_repository_flush` operation waits for that background work to complete. This leaves a window where the caller believes the commit is durable but the store has not yet persisted it.
Lore version
lore 0.9.0
Installation method
Built from source
Operating system / architecture
Cross-platform (reproduced on macOS arm64, Linux x86_64, and Windows x86_64)
Steps to reproduce
Using the C API against a fresh local/offline repository:
lore_repository_flush(&globals, &flush_args, callback)before_ExitExpected vs actual behavior
Expected: Either successful commit completion is a durability boundary, or the public API documentation explicitly states that callers must complete
lore_repository_flushbefore acknowledging a save.Actual: Commit completion schedules, but does not await, persistence. A process termination at the successful commit callback can lose the revision that was just reported as complete.
Component
Client (CLI)
Server context
local/offline mode only
Regression?
This reproduced in 0.8.5 at approximately 20% frequency and still reproduces in 0.9.0.
Relevant logs or output