User cannot send messages after accepting invitation - UPDATE operations timeout

[sanity]

Bug Description

When a user accepts an invitation to join a River room, they can successfully read messages (GET operations) but cannot send messages (UPDATE operations timeout). The issue appears to be that the local River state is not properly initialized after accepting an invitation.

Steps to Reproduce

1. User1 creates a room using riverctl room create
2. User1 creates an invitation using riverctl invite create <room_owner_key>
3. User2 accepts the invitation using riverctl invite accept <invitation_code> --nickname User2
4. User1 can successfully send messages to the room
5. User2 can successfully list messages in the room (GET operation works)
6. User2 attempts to send a message but gets: Error: Timeout waiting for update response

Expected Behavior

After accepting an invitation, User2 should be able to both read AND write messages to the room.

Actual Behavior

User2 can only read messages but cannot send them. UPDATE operations timeout.

Root Cause Analysis

After debugging, I found that User2's local River state (rooms.json) is not properly initialized after accepting the invitation:

User1's rooms.json (working):

{
  "rooms": {
    "<contract_key>": {
      "room_config": {
        "owner_member_id": -2587497886351928606,  // Actual owner ID
        "name": "test-room",
        // ... other config
      },
      "member_info": [
        {
          "member_info": {
            "member_id": -2587497886351928606,
            "version": 0,
            "preferred_nickname": "User1"
          },
          "signature": [...]
        }
      ],
      "messages": [...]
    }
  }
}

User2's rooms.json (broken):

{
  "rooms": {
    "<contract_key>": {
      "room_config": {
        "owner_member_id": 0,  // Not initialized\!
        "name": "Default Room Name",  // Not updated\!
        // ... other config
      },
      "member_info": [],  // Empty\! User2 not added as member
      "messages": []  // Empty even though User2 can read messages via GET
    }
  }
}

Key Findings

1. User2's owner_member_id is set to 0 instead of the actual owner's ID
2. User2 is not added to the member_info array
3. The room name remains as "Default Room Name"
4. User2 can perform GET operations (list messages) but not UPDATE operations (send messages)
5. The UPDATE request never reaches the Freenet peer - it times out at the riverctl/client level

Test Environment

• Freenet version: main branch (as of 2025-08-01)
• River version: Using the version bundled with Freenet
• Test performed using the gateway test framework
• Both users connected to the same local Freenet peer

Logs

User2 attempting to send message:

Command: riverctl --config-dir /tmp/freenet-test-6ruatofk/river-user2 --node-url ws://127.0.0.1:52619/v1/contract/command?encodingProtocol=native --format json message send AUQixAtN72HbTMwBrSg4q6kxPEtxPYe6p7s3MWWsPDsD "Test message from user2"
Return code: 1
STDERR: Error: Timeout waiting for update response

User2 successfully listing messages (showing User1's message):

[
  {
    "author": "4JJOXKTB",
    "content": "Test message from user1 at 2025-07-31 21:09:42.416257",
    "nickname": "User1",
    "timestamp": "2025-08-01T02:09:42.428632638+00:00"
  }
]

Additional Notes

• This issue is reproducible consistently
• Adding delays between operations doesn't help
• The issue is not related to concurrent updates (tested with 5-second delays)
• GET operations work fine, only UPDATE operations fail
• The UPDATE request from User2 never appears in the Freenet peer logs, suggesting it's rejected at the client level

Suggested Fix

The invite accept command should properly initialize the local state with:

1. The correct owner_member_id
2. Add the accepting user to the member_info array
3. Update the room configuration with the actual room details
4. Ensure the user has proper permissions to perform UPDATE operations

This initialization should happen either during the invite accept process or when the user first syncs with the room after accepting the invitation.