feat!: update to latest 1.0.0-rc.0 deps and redb@4#100
Merged
Conversation
|
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh-docs/pr/100/docs/iroh_docs/ Last updated: 2026-05-08T17:06:49Z |
rklaehn
approved these changes
May 8, 2026
| use irpc::{channel::mpsc, LocalSender, WithChannels}; | ||
| use n0_future::task::{self}; | ||
| use n0_future::{ | ||
| task::{self}, |
Contributor
There was a problem hiding this comment.
Weird import. Isn't that just n0_future::task?
This was referenced May 28, 2026
cbenhagen
added a commit
to cbenhagen/iroh-docs
that referenced
this pull request
May 29, 2026
Stores written by iroh-docs 0.94..=0.98 (redb 2.6) carry the old on-disk type tag for variable-width tuples on records-1, records-by-key-1, and latest-by-author-1. Opening them under 0.99+ (redb 4) fails with TableTypeMismatch because the 2 to 4 jump in n0-computer#100 skipped the redb 3.x Legacy<...> migration window. When Store::persistent hits TableTypeMismatch, open the file with redb 3 via Legacy wrappers on the three affected tables, copy everything into a fresh redb 3 file with plain tuple types, and swap files. The original is preserved at <path>.backup-redb-v2-tuples. redb 4 then opens the result. Closes n0-computer#104
cbenhagen
added a commit
to cbenhagen/iroh-docs
that referenced
this pull request
May 29, 2026
Stores written by iroh-docs 0.94..=0.98 (redb 2.6) carry the old on-disk type tag for variable-width tuples on records-1, records-by-key-1, and latest-by-author-1. Opening them under 0.99+ (redb 4) fails with TableTypeMismatch because the 2 to 4 jump in n0-computer#100 skipped the redb 3.x Legacy<...> migration window. When Store::persistent hits TableTypeMismatch, open the file with redb 3 via Legacy wrappers on the three affected tables, copy everything into a fresh redb 3 file with plain tuple types, and swap files. The original is preserved at <path>.backup-redb-v2-tuples. redb 4 then opens the result. Closes n0-computer#104
Frando
pushed a commit
that referenced
this pull request
Jun 1, 2026
## Description Fixes #104. Stores created or opened by iroh-docs 0.94 through 0.98 (redb 2.6) cannot be opened under 0.99+ (redb 4): `Tables::new` fails with `TableTypeMismatch` on `records-1`, `records-by-key-1`, and `latest-by-author-1`. The issue write-up has the full root cause analysis. In short, redb 3.0 changed the on-disk type tag for variable-width tuples, and #100 jumped from redb 2.6 straight to redb 4.1, skipping the redb 3.x release line where the documented `Legacy<...>` migration would have run. By the time a user is on 0.99+, the migration window is closed inside any release pinned to redb 4 (which dropped the `Legacy` type entirely). This PR keeps redb 4.1 as the primary dependency and adds redb 3.1 alongside it for the one job that requires it. When `Store::persistent` sees a `TableTypeMismatch` from the initial `Tables::new`, it: 1. Opens the file with redb 3. 2. Reads the three affected tables through `Legacy<...>` wrappers (which match the redb 2.6 stamping). 3. Copies every table into a fresh redb 3 file at a temp path in the same directory, using plain tuple types on the write side. That commit re-stamps the metadata as `Internal2`. 4. Renames the original to `<path>.backup-redb-v2-tuples` and persists the temp file in its place. redb 4 then opens the result normally and the existing data migrations (`migrations::run_migrations`) run as before. Changes: - `Cargo.toml`: add `redb_v3 = { package = "redb", version = "3.1" }`. - `src/store/fs/migrate_redb_v2_tuples.rs` (new): migration logic. Uses the same `migrate_table!` / `migrate_multimap_table!` macro style as the existing `migrate_v1_v2.rs`. - `src/store/fs.rs`: `Store::persistent` catches `TableError::TableTypeMismatch` from `new_impl`, runs the migration, and retries once. - Tests: one synthesises a redb 2.x-shaped file by writing through `Legacy<...>` with redb 3, then asserts (a) redb 4 rejects it before migration, (b) `Store::persistent` succeeds, (c) the backup file is created, and (d) all rows survive when read back with redb 4 plain types. A second test asserts a fresh open never creates a backup file. ## Breaking Changes None for users already on 0.99+. Users coming from 0.94..=0.98 will see their original file renamed to `<path>.backup-redb-v2-tuples` on first open. The new file at the original path holds the same data. ## Notes & open questions - redb 3 needs to ship as long as we want to migrate stores written by 0.94..=0.98 directly. Dropping the dependency later means those users would have to install an intermediate iroh-docs release first. - The fixed-width tuple tables (`namespaces-2`, `sync-peers-1`) are not affected, because variable-width tuples are the only thing redb 3 changed the tag for. The migration still copies them so the resulting file is a clean redb 3 write top to bottom. ## Change checklist - [x] Self-review. - [ ] Documentation updates following the [style guide](https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#appendix-a-full-conventions-text), if relevant. - [x] Tests if relevant. - [x] All breaking changes documented.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.