feat(idxdb-store): decouple StateSync from Store - #23
Open
WiktorStarczewski wants to merge 6 commits into
Open
Conversation
Migrated from 0xMiden/rust-sdk#2132 (author: juan518munoz) as part of the web-sdk split. Original PR: 0xMiden/rust-sdk#2132 This is the idxdb-store side of the StateSync/Store decoupling work (closes miden-client #2102). The Rust client-side changes stay on the original PR.
…-from-store) Temporarily retarget the workspace miden-client / miden-client-sqlite-store git deps from `next` to the upstream PR branch so this PR's CI can compile against `miden_client::sync::PublicAccountDelta` (added in 0xMiden/rust-sdk#2132 and not yet released). Revert before merge — see CLAUDE.md / PR description for the merge sequence.
WiktorStarczewski
added
the
no changelog
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
Now that miden-client#1835's wiktor-storekeys branch has been merged with miden-client@dab6cf7b (the same snapshot of next that web-sdk currently pins), the dep retarget that #23/#25/#26/#31 use works for this PR too. Local 'cargo check --workspace --target wasm32-unknown-unknown' is clean (was 23 errors before the upstream merge, due to the alpha-protocol mismatch the PR description mentions). Revert before merge — see PR description merge gate.
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
Observed flake: probe returns HTTP 200 once on the first attempt that clears the connection-refused phase, exits, tests start, ALL tests fail with 'TypeError: Failed to fetch' to the gRPC backend. The single-probe gate isn't strict enough — a one-shot 200 (e.g. tonic-health responding before the rest of the dispatcher is fully wired) currently passes. Upgrade the readiness signal to N consecutive HTTP successes spaced PROBE_INTERVAL apart (defaults: 3 successes, 0.5s apart), so the probe only declares the server ready after ~1s of demonstrably-stable response. Any non-success in the streak resets it to zero and the slow-poll loop resumes — so a momentary blip during init doesn't get counted twice on either side. Tracked occurrences across recent PR runs: web-sdk PR #23 ci-shard-4, PR #29 ci-shard-1 + ci-shard-4, PR #27 multiple shards.
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
Observed flake: probe returns HTTP 200 once on the first attempt that clears the connection-refused phase, exits, tests start, ALL tests fail with 'TypeError: Failed to fetch' to the gRPC backend. The single-probe gate isn't strict enough — a one-shot 200 (e.g. tonic-health responding before the rest of the dispatcher is fully wired) currently passes. Upgrade the readiness signal to N consecutive HTTP successes spaced PROBE_INTERVAL apart (defaults: 3 successes, 0.5s apart), so the probe only declares the server ready after ~1s of demonstrably-stable response. Any non-success in the streak resets it to zero and the slow-poll loop resumes — so a momentary blip during init doesn't get counted twice on either side. Tracked occurrences across recent PR runs: web-sdk PR #23 ci-shard-4, PR #29 ci-shard-1 + ci-shard-4, PR #27 multiple shards.
This was referenced Apr 30, 2026
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
Observed flake: probe returns HTTP 200 once on the first attempt that clears the connection-refused phase, exits, tests start, ALL tests fail with 'TypeError: Failed to fetch' to the gRPC backend. The single-probe gate isn't strict enough — a one-shot 200 (e.g. tonic-health responding before the rest of the dispatcher is fully wired) currently passes. Upgrade the readiness signal to N consecutive HTTP successes spaced PROBE_INTERVAL apart (defaults: 3 successes, 0.5s apart), so the probe only declares the server ready after ~1s of demonstrably-stable response. Any non-success in the streak resets it to zero and the slow-poll loop resumes — so a momentary blip during init doesn't get counted twice on either side. Tracked occurrences across recent PR runs: web-sdk PR #23 ci-shard-4, PR #29 ci-shard-1 + ci-shard-4, PR #27 multiple shards.
WiktorStarczewski
added a commit
that referenced
this pull request
Apr 30, 2026
Observed flake: probe returns HTTP 200 once on the first attempt that clears the connection-refused phase, exits, tests start, ALL tests fail with 'TypeError: Failed to fetch' to the gRPC backend. The single-probe gate isn't strict enough — a one-shot 200 (e.g. tonic-health responding before the rest of the dispatcher is fully wired) currently passes. Upgrade the readiness signal to N consecutive HTTP successes spaced PROBE_INTERVAL apart (defaults: 3 successes, 0.5s apart), so the probe only declares the server ready after ~1s of demonstrably-stable response. Any non-success in the streak resets it to zero and the slow-poll loop resumes — so a momentary blip during init doesn't get counted twice on either side. Tracked occurrences across recent PR runs: web-sdk PR #23 ci-shard-4, PR #29 ci-shard-1 + ci-shard-4, PR #27 multiple shards.
This was referenced Apr 30, 2026
…tatesync-decouple
…p manual dep retarget Brings in the auto-patch infrastructure landed in #65 (composite action + readiness gate + lefthook guard + dev script). Drops the manual git+branch retarget on Cargo.toml: the 'Client PR: #2132' marker on this PR's description now drives the dep injection at CI runtime. Cargo.toml + Cargo.lock are now byte-identical to origin/next.
Collaborator
|
@WiktorStarczewski rebased this PR to |
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.
Migrated from miden-client#2132 (author: @juan518munoz) as part of the web-sdk split (web/WASM components moved out of miden-client into this dedicated repo — see miden-client #1992 / #2135).
This is the idxdb-store side of the
StateSync/Storedecoupling work. Closes the web-sdk portion of miden-client#2102. The Rust client-side changes (the bulk of the original PR) stay on miden-client#2132.The upstream dependency (miden-client#2132) is now merged and shipped in miden-client 0.15.0, which
nextpins, so the functionalPublicAccountUpdate::Deltahandling already landed onnextinline. The remaining change here is a refactor ofcrates/idxdb-store/src/sync/mod.rs: it extracts the inline delta-apply path intoapply_public_account_deltaandupdate_smt_forest_for_delta(plus aSmtForestDeltaUpdatestruct), with no behavior change. The branch has been re-synced withnext.