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-05T15:25:45.989210611+00:00
Issue hash: 31c5d7e4

Value Assessment

The problem described touches a core part of how River updates room contracts: the owner-side migration routine in ui/src/components/app/freenet_api/room_synchronizer.rs attempts to deliver an AuthorizedUpgradeV1 pointer inside ChatRoomStateV1, but it fills the rest of the state with Default::default(). Because the old contract validates the entirety of the submitted state before accepting an UPDATE, that “empty” configuration (zeroed owner ID, no members, missing cryptographic context) triggers State verification failed: Invalid signature, meaning the upgrade pointer never sticks. Any room still hosted on the legacy contract version therefore has its migration path broken, so all users of that room (owners and followers) see repeated fetch/update failures and can’t follow the migration pointer to the new WASM; the issue therefore impacts every actual room migration and leaves the UI stuck in a perpetual timeout loop.

Fixing this is strategically important because contract migration is one of the main ways the River team evolves the protocol without breaking room data. The upgrade pointer is expressly there for old clients to locate and subscribe to the new contract, which is what lets the newer UI continue to serve rooms that were created before a WASM bump. When that mechanism fails, the project’s goals of decentralization and smooth upgrades are frustrated: any meaningful room changes, new encryption patches, or delegate improvements that require a contract bump can’t roll out to the installed base. A migration regression at this level goes straight against the roadmap items around contract delivery, smart contract safety, and backwards compatibility.

It also blocks other work because the ChatRoomStateV1 upgrade path is foundational for introducing new contract-based features—without a functioning migration signal, teams can’t confidently change WASM and must keep supporting older versions indefinitely. Moreover, the inability to set the upgrade pointer means no clients can complete the handoff, and the new contract subscription never stabilizes, so even unrelated UI work that depends on the new contract state can’t be validated. Because every future contract release will hit this same invalid-state rejection, it’s urgent to address the upgrade payload (either by making the UPDATE a delta or copying the current full state alongside the pointer) before the next release window; otherwise, no existing room on an older contract can ever be migrated again, locking in technical debt and security risks.

Cost Assessment

Fixing the issue only requires touching the owner-send path in room_synchronizer: after the PUT to the new contract, the owner currently builds an ChatRoomStateV1 with only the upgrade field populated and everything else left at Default (ui/src/components/app/freenet_api/room_synchronizer.rs:475-508). That Default state has a zeroed AuthorizedConfigurationV1, empty members, missing secrets, etc., but the room contract’s verifier (see the ChatRoomStateV1 definition in common/src/room_state.rs:27-74) checks the full configuration, members, secrets, and owner signature, so the update is rejected before it even reaches the new upgrade pointer. The rest of the migration machinery—Rooms::merge tracking migrated_rooms (ui/src/room_data.rs:563-620) and the ROOOMS map holding the real room_state—already has everything needed to build a valid state, so the scope stays within the synchronizer helper that sends the upgrade pointer.

The logical fix is to take the stored room_data.room_state, clone it, set upgrade to OptionalUpgradeV1(Some(authorized_upgrade)), and send that clone in the UpdateData::State so the contract sees the legitimate configuration, members, secrets, and signature it expects. That’s a modest change (one helper block) but it has to be done carefully: keep the read lock on ROOMS short so you only clone the current state, avoid mutating the live state (the owner’s local state shouldn’t suddenly contain its own upgrade pointer unless that’s desired), and ensure the serialized state you send is identical to what the new contract already guards besides the new upgrade pointer. There’s no need to touch other subsystems; the data for the upgrade pointer (AuthorizedUpgradeV1, UpgradeV1, and the blake3 contract hash) is already being computed in this block, so the change is scoped to constructing and serializing the correct ChatRoomStateV1 instance.

The biggest risk is regression of the migration path: if you accidentally mutate the owner’s cached state or send a stale snapshot, you could reintroduce validation failures or race with the PUT to the new contract. Testing therefore has to be functional—run the UI against an old room contract version (the reproduction steps mentioned in the issue) and verify that the UPDATE succeeds and the old contract now serves the upgrade pointer, which in turn lets other clients follow it instead of timing out. There isn’t currently an automated test for this, so plan for a manual/integration check (e.g., cargo make dev or freenet local) that performs the migration flow, confirms the old contract accepts the update, and then that the new contract is actually followed; once that’s proven, the regained pointer should keep migrations working without touching unrelated behavior.

---

Generated by issue-prioritizer