block store implementation (littDB)#3600
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #3600 +/- ##
==========================================
- Coverage 59.02% 58.21% -0.81%
==========================================
Files 2215 2146 -69
Lines 182530 174482 -8048
==========================================
- Hits 107741 101581 -6160
+ Misses 65092 63865 -1227
+ Partials 9697 9036 -661
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
PR SummaryHigh Risk Overview Adds a durable blocksim is rewired to generate FullCommitQC + block batches, supports mem and litt backends, resume after restart (reverse iterators + optional QC-ahead backfill), and batch-at-a-time shutdown semantics. Litt Put/PutBatch docs now state that with sharding factor 1, crash durability preserves issue order across writes; a new segment test locks the single-shard contiguous prefix recovery property that littblock relies on. Reviewed by Cursor Bugbot for commit 813881a. Bugbot is set up for automated code reviews on this repo. Configure here. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 4 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 1b0c8c8. Configure here.
wen-coding
left a comment
There was a problem hiding this comment.
I mainly checked the block/QC contract and it looks good to me. I'll leave the review of implementation details to other reviewers.
| // writes landed): drop the tail of its value file, then flip its metadata | ||
| // back to unsealed so LoadSegment re-runs recovery on reopen. | ||
| valPath, metaPath := largestValueSegmentFiles(t, dir) | ||
| truncateFileBy(t, valPath, 16) |
There was a problem hiding this comment.
nit: I assume this assumes one block is always > 16 bytes (which is almost always true)
| } | ||
| if qcsErr != nil { | ||
| return fmt.Errorf("failed to flush qcs table: %w", qcsErr) | ||
| if err := s.table.Flush(); err != nil { |
There was a problem hiding this comment.
do we have a test which does: write -> Flush -> kill process -> reopen -> assert data is present?

Describe your changes and provide context
Implements the blockDB using littDB. Small tweaks to blockDB API.
Testing performed to validate your change
unit tests