Syncing fails with iroh_docs version 0.91.0, but works correctly with version 0.35.

[appeathoul]

In iroh version 0.91.0, joining a shared document works correctly the first time using the following code. However, on the second join attempt with the same code:

• Updates from the remote document are received and synchronized correctly.

 let doc = node.docs.import(ticket).await?;

• But updates made locally only trigger LiveEvent::InsertRemote on the remote node, without actually downloading the corresponding blob content.

• Rejoining the same sync node has no effect.

• Interestingly, if a new node joins the document for the first time, everything works as expected.

This issue does not exist in iroh version 0.35 — synchronization works both ways as intended.

[appeathoul]

Versions

iroh 0.92

iroh-blobs 0.94

iroh-docs 0.92

Description

The previous issue where local node data could not be synced to the remote after joining multiple times has been fixed. However, I’m now encountering new problems:

1. Multiple docs in a single blobs instance fail to sync on first join

• Example: I have multiple docs (node, folders, previews) under the same blobs instance.

• When I try to join multiple docs using import (ticket):

  • If NAT hole punching fails and the connection falls back to relay proxy mode, most of the time only the first doc (e.g. the node doc) is synced.

  • I can see new data in LiveEvent::InsertRemote.

  • But it never reaches LiveEvent::ContentReady, which means the files are not actually downloaded—only the instance structure is synced.

  • This issue cannot be reproduced in a LAN environment.

• Note: This behavior did not occur with iroh-blobs 0.93. It appears to be a regression introduced in 0.94.

2. Repeatedly joining a remote node may cause sync failure

• When the local node repeatedly joins the same remote node, there’s a chance that newly added local data cannot be synced to the remote node.

• This issue can be reproduced in a LAN environment.

Question

Are these issues caused by incorrect usage on my part, or are they actual bugs?
Looking forward to your feedback—thanks!

[Frando]

Hi! Thanks for the report.

I tried to put the situation you are describing into an integration test, see #70. The test passes though.

Could you try to come up with a reproducible example somewhere that I can run to debug your case further?

[appeathoul]

Description

After shutting down and recreating an iroh network, synchronization with the relay server fails.
This issue consistently occurs when importing multiple tickets after restarting the endpoint.

🧩 Environment

OS: macOS 14.7.8 (23H730) — ARM & x86

Rust: 1.89.0

Network: Cross-domain

⚙️ Steps to Reproduce

1. Create an iroh network:

let endpoint = iroh::Endpoint::builder()
    .discovery_n0()
    .secret_key(secret_key)
    .relay_mode(RelayMode::Custom(default_relay_map()))
    .bind()
    .await?;

2. Shut down the network:

router.shutdown().await?;

3. Recreate the iroh network using the same code and Import multiple tickets using

 doc.import(ticket).await?;

4. Observe the logs — the following warnings appear during runtime:

WARN  Lost connection to relay server
WARN  Failed to handshake with relay server

doc LiveEvent

SyncEvent { peer: PublicKey(efe920be235e3327f48e23b37fa84fca6aaf0e1e5b516c3c4c446159babf171a), origin: Connect(DirectJoin), finished: SystemTime { tv_sec: 1760169366, tv_nsec: 828281000 }, started: SystemTime { tv_sec: 1760169336, tv_nsec: 823947000 }, result: Err("Failed to establish connection") }

❗ Actual Behavior

The network fails to reconnect to the relay server, causing document synchronization errors.

✅ Expected Behavior

The recreated iroh instance should reconnect successfully and continue syncing data normally.

📎 Additional Notes

The issue occurs consistently when multiple docs are imported after reinitialization.

May be related to internal relay state persistence or endpoint reuse after shutdown.

Code

I have uploaded a test project
iroh-test

[appeathoul]

Hi! Thanks for the report.

I tried to put the situation you are describing into an integration test, see #70. The test passes though.

Could you try to come up with a reproducible example somewhere that I can run to debug your case further?

Hi!, Can this issue be fixed, or is it caused by the way I’m using it? Thank you.