PUT succeeds on remote peer but publisher never receives SuccessfulPut

[sanity]

Observed behavior

• River UI / riverctl publishing a room forwards the PUT (01KA2Q6FYY… / 01KA2R1W…) to peer v6MWKgqHiBMNcGtG and then times out (/tmp/freenet.log:13218-13324, 15545-15764).
• The remote node (Nova gateway at 5.9.111.215:31337) actually stores the contract and emits SuccessfulPut, but when it tries to send the ack back it attempts to connect to v6MWKgqKCpsc5rkG at 127.0.0.1:36078 and fails with TransportError("failed while establishing connection, reason: max connection attempts reached") (see journalctl -u freenet-gateway --since "2025-11-14 21:10" --until "21:20" | grep 01KA2R1W285XGJG4M0CNWPNB81).
• Because the ack never reaches the publisher, River UI stays stuck on "Subscribing to room…" and riverctl room create reports Timeout waiting for PUT response, even though the remote peer has the contract.
• The invite-accept tab later performs a GET (01KA2Q6VEN…) that also times out because the gateway cannot see the contract locally (/tmp/freenet.log:13280-13448).

Expected

• The publishing node should persist the contract locally and respond with PutResponse even if downstream peers fail to deliver SuccessfulPut.
• GET/SUBSCRIBE issued via the same node should be served from the local cache when possible; they should not stall forever waiting on the same remote peer that already timed out.

Steps to reproduce

1. Run freenet local on technic.locut.us (gateway WebSocket at ws://127.0.0.1:7509).
2. cd ~/code/freenet/river/main && cargo run --bin riverctl -- room create --name "cli-test" --nickname "owner".
3. Observe the CLI error Timeout waiting for PUT response after 10 seconds; tail /tmp/freenet.log for the PUT/GET transaction IDs above.
4. On Nova (ssh nova.locut.us) run sudo journalctl -u freenet-gateway --since "2025-11-14 21:10" --until "2025-11-14 21:20" | grep 01KA2R1W285XGJG4M0CNWPNB81 to confirm the remote peer stored the contract and then attempted to connect back to 127.0.0.1:36078.

Impact

• River UI invite accept flows hang forever on a single-node setup talking to a remote peer.
• riverctl room create cannot complete, preventing automated tests/deployments.

Logs available upon request (/tmp/freenet.log, Nova journalctl excerpts`).

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-bug (98% confidence)
• P-high (90% confidence)
• E-medium (75% confidence)
• A-networking (95% confidence)
• A-contracts (85% confidence)

Reasoning: The report describes a clear malfunction: PUT is stored on a remote peer but the publisher never receives the SuccessfulPut acknowledgement due to failed connection attempts back to the publisher (network/transport behavior). This breaks River UI flows and prevents riverctl room create and automated tests, so it is a bug with high priority. The root cause appears related to networking/connection handling (peers connecting back to localhost) and the contract persistence/ack logic (should persist locally and respond even if downstream ack fails), so both A-networking and A-contracts are relevant. Fix likely requires moderate changes to connection/ack handling and local persistence/response behavior, so E-medium.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.

[sanity]

Closing: This was a symptom of #2087 (connect handshake advertising loopback/private addresses). The fix in PR #2090 and PR #2142 addressed the underlying cause - the SuccessfulPut messages were being sent to unreachable private addresses (127.0.0.1) because the joiner's observed public address wasn't being propagated correctly through the connect handshake.

With the address propagation fixed, remote peers now send SuccessfulPut to the correct external address.

[AI-assisted - Claude]