Contract migration sends invalid state to old contract, causing 'Invalid signature' error

[iduartgomez]

Problem

When a room contract is migrated to a new WASM version, the migration code sends an upgrade pointer UPDATE to the old contract. This UPDATE fails with:

UPDATE operation failed: invalid contract update, reason: State verification failed: Invalid signature: signature error

This was observed in the browser console while the UI migrated room XQTMFW5V from old contract oW3AFr9RE15sm9d1dZwEQVMjaNJKwsyNbGUP1ptekE6 to new contract GD238LC8mu6FHfp33w9DVATyKaCa9n5CNnKUzyANzodj.

Root Cause

In ui/src/components/app/freenet_api/room_synchronizer.rs around line 449-453, the upgrade state is constructed as:

let upgrade_state = ChatRoomStateV1 {
    upgrade: OptionalUpgradeV1(Some(authorized_upgrade)),
    ..Default::default()   // ← BUG: empty/invalid state for all other fields
};

The ..Default::default() produces an empty configuration (with zeroed owner_member_id), empty members, etc. The old contract's state verification checks the entire submitted state for consistency and rejects it because the configuration fields are invalid/empty.

Expected Behavior

The upgrade pointer should be sent as a delta (not a full state replacement), or the full current room state should be included alongside the upgrade pointer so the old contract's validation passes.

Steps to Reproduce

1. Have a room created with an older contract version
2. Connect with a new River UI that triggers contract migration
3. Observe the console error: UPDATE operation failed: ... Invalid signature: signature error

Impact

• The upgrade pointer is never set on the old contract
• Other clients can't follow the migration pointer to the new contract
• The new contract subscription eventually fails with repeated timeout errors

Related

• feat: Graceful room contract WASM upgrades #63 (Graceful room contract WASM upgrades)

[sanity]

Issue Priority Assessment

Generated: 2026-03-12T22:32:53.000512219+00:00
Issue hash: 0d091736

Value Assessment

The issue is still very much relevant because the code path that constructs the upgrade state still zeroes out everything except the upgrade pointer. In ui/src/components/app/freenet_api/room_synchronizer.rs around lines 520‑560 the owner-specific branch builds ChatRoomStateV1 with upgrade: OptionalUpgradeV1(Some(authorized_upgrade)) and the rest comes from ..Default::default(), which produces an empty configuration, member list, etc. Submitting that to the old contract violates its full-state verification and triggers the “invalid signature” failure described in the issue, so the state never actually lands. Nothing later in the file substitutes a delta or reuses the current state, so the symptoms from the report—missing upgrade pointer and migration timeouts—would still occur today.

The impact on users is severe for any room whose contract is updated: newer clients can’t signal the migration pointer to the old contract, which means older clients can’t find the new contract key and everyone ends up resubscribing repeatedly without success. The new contract subscription eventually fails with repeated timeouts because the upgrade pointer never existed, so rooms remain effectively stuck in the pre-migration state. That affects anyone trying to keep a room up to date on a rolling release and could block room owners from deploying new contract logic; it’s not a cosmetic bug but a hard failure of the upgrade flow.

Addressing this is aligned with the project’s core goals around safe, permissionless contract upgrades and the “state authorization” guarantees highlighted in AGENTS.md, because this bug breaks the assurance that every contract transition is cryptographically valid and discoverable by clients. It also blocks downstream work that assumes migration pointers can be trusted: for example, any UX that notifies members about migrations or automations that switch to the new contract key will be waiting on a pointer that never exists.

Given that the contract upgrade path is part of regular releases and is already failing under the current code, the urgency is high—every new deployment that changes the room module’s WASM runs into this same deadlock. Fixing it unlocks immediate stability for upgrades and prevents the otherwise inevitable rollback or manual intervention, so it should be prioritized before shipping another WASM version.

Cost Assessment

The snippet at ui/src/components/app/freenet_api/room_synchronizer.rs:504 still constructs the upgrade payload by only setting upgrade and falling back to ..Default::default(), so the client is still PUTting a full state whose configuration/member lists/secrets are zeroed. Because ChatRoomStateV1 (defined at common/src/room_state.rs:26) is composable and requires every field to be signed (e.g., AuthorizedConfigurationV1 and the member set), submitting a mostly empty state still produces the “Invalid signature” error described in #127. Nothing in the repo indicates this code path has been refactored away, so the issue remains actionable with the same root-cause: the migration update is replacing state instead of appending a delta or copying the real room_state.

Fixing it is largely confined to that block in room_synchronizer.rs, but the change touches the same data that is read earlier in the migration loop (room_state_bytes, room_data.room_state, etc.). You either need to build the upgrade state from a clone of room_data.room_state before setting the upgrade field or, better yet, send just a delta that sets optional_upgrade. Either approach requires reading the existing state from ROOOMS (the room_data map used to PUT the new contract state) and reusing it for the old-contract update instead of Default::default(). No other subsystems look involved, but you must keep the parameters/owner signing keys consistent so the upgrade pointer is still authorized.

The complexity comes from ensuring the ChatRoomStateV1 (or its delta) you send still passes the contract’s verify path. That means reconstructing all the fields that the migration validation expects—configuration, members, member_info, secrets, and messages—so signatures remain valid, or using the existing delta machinery (ChatRoomStateV1Delta updates like the ones covered in contracts/room-contract/tests/integration_tests.rs:235) to avoid touching the whole state. Mistakes here can corrupt the state tree, introduce invalid sequences of deltas, or leave the upgrade pointer incomplete, which is why the risk is moderate even though the fix itself is localized.

There are no external signups or approvals needed, but the testing effort is non-trivial: you need to exercise a contract migration path so the old contract accepts the upgrade pointer (the integration test suite in contracts/room-contract/tests/integration_tests.rs already walks through deltas, and the UI has to hit a real Freenet node to recreate the migration scenario). That means building the UI with example data or running against a local Freenet node, publishing both contracts, and verifying the upgrade pointer is accepted. Overall, the implementation cost feels moderate—only one module needs a change, but you must be careful with cryptographic validation and invest extra time in regen-sized integration testing before marking the issue done.

---

Generated by issue-prioritizer

[iduartgomez]

@claude is this fixed?

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.