River Chat Messages Not Propagating Between Peers Despite Successful Subscriptions #1775
Description
River Chat Messages Not Propagating Between Peers Despite Successful Subscriptions
Description
In River chat application, messages sent by one user are not visible to other users in the same room, even though the users are subscribed to the contract and the UPDATE operations complete successfully. This is a critical issue that breaks the core functionality of the decentralized chat application.
Environment
- Freenet Core: Latest version from
/home/ian/code/freenet/freenet-core/main - River: v0.1.9 (with
return_contract_code: truemodification) - Test Setup: Multi-machine test with 1 gateway and 2 peers
Steps to Reproduce
- Start a gateway and two peers in a test network
- Create a room on Peer 1 (Alice)
- Create an invitation from Alice
- Accept the invitation on Peer 2 (Bob)
- Send a message from Alice
- Send a message from Bob
- List messages from both peers
Expected Behavior
Both Alice and Bob should see both messages:
- Alice's message: "Hello from Alice!"
- Bob's message: "Hello from Bob!"
Actual Behavior
- Alice sees only her own message (1 message)
- Bob sees both messages (2 messages)
Root Cause Analysis
Through detailed log analysis, the issue appears to be with the subscription/notification mechanism:
1. Subscription Works
When Bob accepts the invitation, the logs show successful subscription:
RIVER] INFO ACCEPT: sending SUBSCRIBE for contract 3ZDJxPGeQSc8NZoNNcNh8D3VB9W4PCTQhqrVTNjwVNHG
[RIVER] INFO Successfully subscribed to contract
2. UPDATE Operations Succeed
When Bob sends a message, the UPDATE operation completes successfully:
[GW] INFO Successfully updated a value for contract 3ZDJxPGeQSc8NZoNNcNh8D3VB9W4PCTQhqrVTNJwVNHG @ Some(Location(0.6788392870787601))
[GW] INFO UPDATE operation 01K3492R581944JEBCEZX686R4 transitioning to Finished state
The gateway confirms it has subscribers: has_subscribers: true
3. Update Notifications Not Delivered
Despite the successful UPDATE and active subscriptions:
- Alice's peer (peer1) never receives any UPDATE notification from the gateway
- When Alice performs a GET operation, she retrieves her locally cached state
- The cached state only contains her own message
4. Contract State Divergence
This results in different contract states on different peers:
- Gateway has the complete state (both messages)
- Bob's peer has the complete state (both messages)
- Alice's peer has stale state (only her message)
Technical Details
Transaction Flow
-
Bob's UPDATE (TX: 01K3492R581944JEBCEZX686R4):
- Peer 2 → Gateway: UPDATE request
- Gateway: Processes and stores update
- Gateway: Should notify subscribers ❌ (This appears to be failing)
- Peer 1: Never receives notification
-
Alice's GET:
- Returns cached state:
ContractState(data: [0xa66d636f6e666967...]) - Cache contains only Alice's message
- Returns cached state:
Relevant Code Paths
The issue likely lies in the subscription notification mechanism:
- Contract update handling:
crates/core/src/operations/update.rs - Subscription management:
crates/core/src/contract/mod.rs - Network message propagation:
crates/core/src/node/network_bridge/p2p_protoc.rs
Impact
This bug makes River unusable as a multi-user chat application since users cannot see each other's messages in real-time. It affects the core value proposition of Freenet as a platform for decentralized applications.
Workaround
Currently, the only way to see updated messages is to:
- Restart the River client
- Perform a fresh GET operation (which might route to a peer with updated state)
This is not a viable solution for a chat application.
Logs
Full test logs are available showing:
- Successful peer connections
- Successful subscription operations
- Successful UPDATE operations
- Missing UPDATE notifications to subscribed peers
Test command to reproduce:
cd /home/ian/code/freenet/freenet-testing-tools/multi-machine-test
cargo run -- river --riverctl /home/ian/code/freenet/river/target/release/riverctl --output-dir /tmp/river_test_outputRelated Issues
- This may be related to the earlier issue where GET operations were timing out (fixed by setting
return_contract_code: true) - The underlying problem appears to be with how Freenet handles distributed contract state synchronization
Priority
Critical - This breaks the fundamental functionality of River and potentially affects all Freenet applications that rely on real-time state synchronization between peers.