Skip to content

refactor(sqlite-storage): extract DBHead to vbare-versioned protocol crate#4815

Open
NathanFlurry wants to merge 1 commit intoengine-stabilize/sqlite-origin-renamefrom
engine-stabilize/sqlite-storage-vbare-protocol
Open

refactor(sqlite-storage): extract DBHead to vbare-versioned protocol crate#4815
NathanFlurry wants to merge 1 commit intoengine-stabilize/sqlite-origin-renamefrom
engine-stabilize/sqlite-storage-vbare-protocol

Conversation

@NathanFlurry
Copy link
Copy Markdown
Member

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Copy link
Copy Markdown
Member Author

NathanFlurry commented Apr 27, 2026

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

@claude
Copy link
Copy Markdown

claude Bot commented Apr 27, 2026

Code Review — refactor(sqlite-storage): extract DBHead to vbare-versioned protocol crate

Overall this is a clean extraction that follows the established vbare versioning pattern used by other protocol crates in the repo. The structure is correct and the mechanical changes are consistent across all call sites. A few things worth addressing before this ships:


Breaking Change: Legacy format no longer readable

The old decode_db_head in types.rs had two fallback paths:

  1. Decode as the new format (with origin field).
  2. Decode as the legacy LegacyDBHead (without origin), defaulting origin to CreatedOnV2.

Both paths are now gone. The new versioned::decode_db_head calls deserialize_with_embedded_version, which expects a 2-byte LE version prefix. Any existing stored bytes — including data written by the old serde_bare::to_vec path — have no version prefix and will produce a deserialization error at read time.

The test decode_db_head_defaults_legacy_rows_to_created_on_v2_origin was deleted without explanation. If there are any deployed actors with rows in the old format, this will cause read failures after deploy.

Questions:

  • Is a migration handled in a downstack PR in this Graphite stack?
  • If not, does deserialize_with_embedded_version have any fallback for un-prefixed data?

Per CLAUDE.md: "Never modify an existing published *.bare runner protocol version unless explicitly asked to do so." This is a new crate so that rule doesn't apply here, but the on-disk compatibility concern is similar in spirit.


Minor: Inconsistent ownership at encode boundary

types::encode_db_head takes head: &DBHead but internally calls versioned::encode_db_head(head.clone()), which takes ownership. This unnecessary clone could be avoided by either:

  • Making versioned::encode_db_head accept &v1::DBHead and cloning inside only if vbare forces it, or
  • Changing all call sites to pass by value (most are already constructing a temporary).

Not a correctness issue, just a minor inconsistency.


build.rs path resolution

The 3-parent() walk from CARGO_MANIFEST_DIR to find the workspace root is consistent with the other protocol crates (e.g. envoy-protocol), so this is fine as-is. Just worth noting that it will silently break if the crate moves to a different nesting depth.


Nit: PR description is empty

The PR body has no description or test plan. Since this is a DRAFT that's fine for now, but should be filled in before promotion — especially given the migration risk above.


What looks good

  • The vbare versioning pattern (OwnedVersionedData, serialize_with_embedded_version, deserialize_with_embedded_version) is applied correctly and matches the other protocol crates.
  • The v1.bare schema accurately reflects the struct fields.
  • All 9 call sites in shard.rs, worker.rs, open.rs, read.rs, quota.rs, commit.rs, and the pegboard integration test are consistently updated.
  • SQLITE_STORAGE_PROTOCOL_VERSION = 1 is correctly set for the initial introduction.
  • The free-function API (new_db_head, encode_db_head, decode_db_head) is cleaner than the previous DBHead::new associated method.
  • The inline comment in v1.bare pointing future changes toward adding a v2.bare is a good guardrail.

@NathanFlurry NathanFlurry marked this pull request as ready for review April 27, 2026 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant