old spaces fail to sync file contents

[Konfetti030]

@grishy I think you are the only person who could help here. Could you please have a look on it?

Describe the bug

After fixing an initial network/configuration issue, old spaces fail to sync file contents (blobs) to a freshly reset client, while newly created spaces work perfectly. The client only sees the metadata (filenames and sizes) of the old files but cannot download them. The server logs show unable to connect errors for the internal peer manager regarding these specific old space IDs. The files are physically present on the server's storage volume.

To Reproduce

Steps to reproduce the behavior:

1. Start the server with a misconfiguration (e.g., malformed external address causing parsing issues) or have the client behind a strict firewall blocking UDP port 33020.
2. Create spaces and add files/images on the client. The sync will fail or remain incomplete.
3. Fix the server configuration and open all necessary TCP/UDP ports.
4. On the client (Windows 10), completely delete the local cache (%AppData%\anytype), restart the app, and log in again with the fixed client-config.yml.
5. Observe that new spaces sync perfectly, but the old spaces only load metadata. Files cannot be opened.

Expected behavior

After resolving network/configuration issues and performing a clean login, the client should be able to fetch all previously uploaded blobs/files from the filenode, just as it does for newly created spaces.

Actual behavior

The client retrieves the space structure (TCP) but hangs when trying to fetch the file contents.
The Docker container logs show constant incoming space.objectSyncRequestStream requests, followed by can't get peers errors for the specific space ID:

INFO  common.commonspace.peermanager  broadcast  {"spaceId": "bafyreib7wghwxjb462xaz4jyduvzu7o3mbeakvtth2wkazvwhwd34ss7au.2thp58xmogff1"}
INFO  common.net.streampool  can't get peers {"error": "unable to connect"}
INFO  rpcLog {"totalDur": 0.000416392, "spaceId": "bafyreib7wghwxjb462xaz4jyduvzu7o3mbeakvtth2wkazvwhwd34ss7au.2thp58xmogff1", "rpc": "space.objectSyncRequestStream"}

Note: The storage folder /data is 518MB, confirming the files were successfully written to the server initially.

Environment
Deployment: AIO container (docker compose)

Version/tag: ghcr.io/grishy/any-sync-bundle:latest (Bundle 1.4.3-2026-04-21)

OS/Arch: Raspberry Pi 5 / Debian Bookworm (ARM64)

Client: Windows 10 (Anytype v0.55.4)

Configuration
docker-compose.yml

YAML
services:
  anytype-sync:
    container_name: anytype-sync
    image: ghcr.io/grishy/any-sync-bundle:latest
    restart: unless-stopped
    ports:
      - '33010:33010'
      - '33020:33020/udp'
    volumes:
      - /mnt/ssd/anytype-data:/data
    environment:
      - ANY_SYNC_BUNDLE_INIT_EXTERNAL_ADDRS=anytype.mydomain.com
      - ANY_SYNC_BUNDLE_INIT_FILENODE_DEFAULT_LIMIT=109951162777600
client-config.yml (generated)

YAML
id: <hidden>
networkId: <hidden>
nodes:
    - peerId: <hidden>
      addresses:
        - quic://anytype.mydomain.com:33020
        - anytype.mydomain.com:33010
      types:
        - coordinator
        - consensus
        - tree
        - file

Additional context
Creating a completely new space with the current clean setup works flawlessly (images/files sync instantly over UDP). It seems the filenode or consensus database has a corrupted index/reference for the old spaces created during the initial failed connection attempt, preventing it from serving the existing files to the newly reset client.

[grishy]

Hey @Konfetti030
Thanks for detailed issue, I like it 😄
But apparently, after checking, I think this is on the Anytype side - the original code. Not the any-sync-bundle.

Can you create a ticket on their forum?
You may link this issue here to the Anytype forum and back.

Notes:
The can't get peers: unable to connect message is probably not the primary cause here.

The important distinction is that space metadata and file blobs are synced via different paths. If the old spaces were created while networking/configuration was broken, the object metadata may have reached the sync node, while file block upload or the filenode spaceId/fileId -> cid binding may not have completed...

[grishy]

I think to add doctor subcommand to any-sync-bundle that may check filenode links and other stuff

[Konfetti030]

Hey @grishy

Thanks for the great analysis!

An internal "doctor" subcommand to check and heal filenode links sounds like an amazing idea and would be highly valuable for the self-hosted community when things go sideways during initial setups.

I have followed your advice and opened an official issue over at the Anytype repository, linking back to this thread:
anyproto/anytype-ts#2227

Let's see what the core devs say regarding the API/bindings. I'll keep you updated here as soon as they reply!

[Konfetti030]

I think to add doctor subcommand to any-sync-bundle that may check filenode links and other stuff
Hi @grishy ,
Unfortunately, I haven't received any response from the developers regarding my issue.
Do you think there are still ways to get in touch with them or find a concrete solution?

[grishy]

@Konfetti030 I implemented an initial version, but it is not fully checked yet - #72
This is a doctor (finds and checks problem states, not a healer).

You may try writing on the Anytype forum instead of GH. Usually, they are more responsive to forum questions.