fix: remove legacy compatibility fallbacks - #585
Conversation
The `Resources` slot budgets no longer exist as runtime constants: the refreshed paseo-next-v2 V16 metadata (spec 3000000) declares `get_stmt_store_slots_per_period`, `get_lite_stmt_store_slots_per_period`, `get_stmt_store_grace_window`, `get_stmt_store_replacement_cooldown` and `get_long_term_storage_claims_per_period` as view functions and drops the matching constants, so the constant-lookup branch could only ever error. Drop the fallback from `read_resource_u32` / `supports_resource_u32`, along with `PersonhoodCollection::slots_per_period_constant` and `Metadata::has_view_function`, which existed only to select it. Refresh the V16 fixture from the live chain and add a primed People fixture so the allowance tests keep scripting only the slot reads they exercise. `StubPlatform` now keys a `state_call` by the runtime API it names, so a test can answer metadata and view reads separately.
…tMetadata `state_getMetadata` answers with whatever version the node serves, V14 on paseo-next-v2, and V14 declares no transaction-extension version map. Metadata fetched that way silently resolves pipeline 0, which signs an extrinsic that looks correct and is not. Both live People chains and both live Asset Hubs answer `Metadata_metadata_at_version(16)`. `fetch_metadata` now returns the runtime-API answer and fails with `MetadataVersionUnavailable` when the runtime does not serve V16. `fetch_legacy_metadata` and its OpaqueMetadata-wrapper branch are gone. The cache tests script the runtime call rather than the legacy RPC, and count its requests to keep pinning one metadata download per spec version. The People capture is included once from `test_fixtures` instead of three times.
Session state is identity-keyed and product KV is one JSON file per product under `storage/`. The readers for the layouts those replaced accepted state no released `truapi-host` binary ever wrote: - the combined `product-storage.json`, split into per-product files and renamed to `product-storage.v1.json.migrated` on first use - `signing-host/sessions/<name>` session directories, with their separate `signing-host/storage/<name>` product storage - the `pairing-host/storage/default` product-storage directory Removing them collapses `SessionProfile` resolution to one path, so `remove_profile_data`'s out-of-tree storage branch, the `remove_named_data` path list, `promote_to_user`'s storage rename, and `list`'s dedup are all unreachable and go too. `legacy_pairing_storage_moves_to_the_first_resolved_user` is rewritten rather than deleted: it is the only cover for carrying product KV written before the username is known into the resolved user's directory, and it now also asserts that carry is persisted rather than held in memory.
Every trait the parser reads is declared `#[crate::async_trait]`, so a return is either the `Pin<Box<dyn Future<Output = T> + Send>>` desugaring or the method's own type. The explicit `impl Future<Output = T> + Send` arm matched neither, and it held the function's only failure path, so `unwrap_future_output` is now infallible. Cover the pass-through tail, which had no test.
…estore The session-store sync's boot tick now calls announce_current after reconciling, so a pairing host receives an opening AuthState (Disconnected included) without calling activateStoredSession.
…store sync task The notifier no longer injects a synthetic initial tick. The sync task reconciles once at boot, announces the outcome, and then loops over real change notifications without announcing, so the one-shot opening state is visible in the control flow instead of depending on the announced guard. Adds a test that a change tick against an unchanged store stays silent.
The spawned task upgrades its weak reference when it first runs and bails if the runtime is already gone, so a pending boot reconcile never keeps a dropped runtime alive or emits to its platform.
Proofs must include the live network suffix or the People runtime rejects them as BadProof.
Remove legacy LTS and PGAS contexts and scope every proof family by the live network suffix. Follow the generation-prefixed Asset Hub ring-root layout used by current mobile clients and runtime.
… drop-legacy-fallbacks # Conflicts: # rust/crates/truapi-server/src/runtime/statement_allowance.rs # rust/crates/truapi-server/src/test_support.rs
Proofs must include the live network suffix or the People runtime rejects them as BadProof.
Remove legacy LTS and PGAS contexts and scope every proof family by the live network suffix. Follow the generation-prefixed Asset Hub ring-root layout used by current mobile clients and runtime.
cd342e4 to
01a9321
Compare
Address review on #587. `read_current_generation` gates on the runtime declaring `MembersSubscriber.CurrentGeneration` before treating an absent value as the `ValueQuery` default, so a renamed pallet or item is named instead of reading as generation 0, and decodes with `decode_all`, so an entry that stops being a bare `u32` fails here rather than yielding the first four bytes of another layout. Either way the failure would otherwise be a key nothing answers and a wait that can only time out. `await_ring_revision` re-reads the generation each poll. A rebuild landing during the wait is what the loop waits through, and a generation read once up front would key every remaining poll at a generation the roots have left. `method_keyed_responses` panics when a method's scripted answers run out instead of replaying the last one, so a script that answers fewer calls than the code makes fails rather than feeding one read's response to another. The Asset Hub fixture is recaptured at spec 3000000, which is what declares `CurrentGeneration`, and the fixtures README records the generation the committed ring-roots value is addressed under. Pins the fourth statement-slot context vector iOS carries, family 2 at period 0 seq 0, where every suffix field is already zero and an offset slip would hide.
… drop-legacy-fallbacks # Conflicts: # rust/crates/truapi-server/src/runtime/statement_allowance.rs # rust/crates/truapi-server/src/runtime/statement_allowance/pgas.rs # rust/crates/truapi-server/src/runtime/statement_allowance/slot.rs # rust/crates/truapi-server/src/test_support.rs # rust/crates/truapi-server/tests/fixtures/README.md
# Conflicts: # rust/crates/truapi-host-cli/tests/live_asset_hub.rs # rust/crates/truapi-server/src/runtime/signing_host/sso_responder.rs # rust/crates/truapi-server/src/runtime/statement_allowance.rs # rust/crates/truapi-server/src/runtime/statement_allowance/pgas.rs # rust/crates/truapi-server/src/runtime/statement_allowance/slot.rs # rust/crates/truapi-server/src/test_support.rs # rust/crates/truapi-server/tests/fixtures/README.md
…state_getMetadata" This reverts commit 91c512a. Unlike the other fallbacks removed here, this one is not unreachable. It fires on any chain that does not serve V16, and which chain a host connects to is the host's choice, not the core's. Both mobile hosts keep the equivalent: iOS retains `state_getMetadata` as a catch around the versioned path (RuntimeFetchOperationFactory.swift), and both negotiate the highest metadata version at or below 16 rather than requiring 16, so they accept V14 and V15. Removing it here would make the core the only host of the three that fails where the others degrade.
|
The Tests section claims a new Also, the body says paseo-next-v2 is spec 3000000; both paseo-next and previewnet report 3002000. Trivial, but the whole argument is version-specific so the number may as well be right. |
|
Both correct, thanks, and the second one had a third stale claim behind it. Fixed in the description:
On the version being load-bearing: I re-ran the suite against freshly fetched 3002000 metadata and all 789 pass unchanged. That also re-confirms the actual argument, since I left the committed fixture at its 3000000 capture rather than re-capturing. The README records spec and capture date, so it is accurate as a historical capture, and swapping in 527KB of binary for an identical test result is churn. Happy to refresh it if you would rather the fixture track the tip. |
Removes four legacy compatibility fallbacks, each verified unreachable against the
live chains rather than the committed fixtures.
Removed
Resourcesconstant fallback. Live paseo-next-v2 (spec 3002000) serves theslot budgets as view functions and no longer declares
StmtStoreSlotsPerPeriodor
LiteStmtStoreSlotsPerPeriod, so the constant branch could only error. Thecommitted V16 fixture predated that and is refreshed from the chain.
product-storage.jsonwith its.v1.json.migratedbackup,signing-host/sessions/<name>, andpairing-host/storage/default. No releasedtruapi-hostbinary ever wrote anyof them.
impl Futurereturn arm in the rustdoc parser. Every trait the codegen readsis
#[crate::async_trait], so that shape never occurs.Tests
Rewritten where they were the only cover for surviving behaviour
(
product_storage_written_before_the_username_carries_into_the_resolved_user, thesession-clear tests); deleted where the removal made them vacuous. New: a
pass-through test for
unwrap_future_output.Considered and kept
The
state_getMetadatafallback infetch_metadatawas removed and then putback. It is the one fallback here that is not unreachable: it fires on any chain
that does not serve V16, and which chain a host connects to is the host's choice,
not the core's. Both mobile hosts keep the equivalent, verified in their app code
rather than inferred: iOS retains
state_getMetadataas a catch around theversioned path (
RuntimeFetchOperationFactory.swift:92-108), and both negotiatethe highest metadata version at or below 16 (
:46, and Android'sRuntimeMetadataFetcher.kt:23) rather than requiring 16, so both accept V14 andV15. Removing it would make the core the only host of three that fails where the
others degrade.
If the strictness is wanted later, the shape to copy is Android's: negotiate, but
assert V16 before calling view functions, so the failure is loud and localised to
the feature that needs it instead of failing the whole metadata fetch.
Follow-up, not here
Metadata::decode's V14/V15 arms are now test-only. Removing them means deletingpaseo-next-v2-metadata.scaleand migrating ~19 test sites, including a frozenknown-answer hash and the test that pins V14/V16 arity disagreement. Whether
decoding older captures stays supported is worth deciding on its own, so the arms
stay and the module doc says they serve frozen fixtures only.
Validation
cargo build --workspace --all-targets(no warnings),cargo +nightly fmt --check,cargo clippy --workspace --all-targets --all-features -- -D warnings,cargo test --workspace(0 failed),cargo check -p truapi-server --target wasm32-unknown-unknown, all against currentmain.The committed V16 fixture is a spec 3000000 capture; the chain has since moved to
3002000. Re-running the suite against freshly fetched 3002000 metadata passes
unchanged, which also re-confirms all five
Resourcesview functions still existthere (
test_fixtures::PEOPLEpanics by name if any is missing). The fixture isleft at its recorded capture rather than churned. Live metadata read from
paseo-people-nextandpreviewnetto confirm the view functions and V16 are served. Ignored live-chaintests were not run.