Ambiguous Configuration Parameters May Cause Synchronization Failure

[8cher]

Have you read a contributing guide?

• I have read CONTRIBUTING.md
• I have searched the existing issues and didn't find any that were similar
• I have considered creating a pull request with fixes instead of a bug report and want to proceed

Current Behavior

According to the description at Configuration,

"If you need to connect external clients, please add 'EXTERNAL_LISTEN_HOSTS' in the .env.override file."

However, in reality, the EXTERNAL_LISTEN_HOST="127.0.0.1" parameter still exists in .env.default. This results in the generated client.yml containing content similar to the following:

- addresses:
    - any-sync-node-1:1001
    - quic://any-sync-node-1:1011
    - my:server:ip:here:1001
    - quic://my:server:ip:here:1011
    - 127.0.0.1:1001
    - quic://127.0.0.1:1011

When the client loads the client.yml configuration file and attempts to create a new space, images fail to synchronize. The developer console shows a 500 error similar to the following:

bafyreic5wofjuzj52wruunuczjhdd4f6tcjjr67nvniv25p3urb7bgw37u:1
GET http://127.0.0.1:47800/image/bafyreic5wofjuzj52wruunuczjhdd4f6tcjjr67nvniv25p3urb7bgw37u?width=1920 500 (Internal Server Error)
Image
kk @ main.js?0.8319832979224048:121292
ik @ main.js?0.8319832979224048:121290
hk @ main.js?0.8319832979224048:121289
Wk @ main.js?0.8319832979224048:121313
Pk @ main.js?0.8319832979224048:121311
Ek @ main.js?0.8319832979224048:121303
jg @ main.js?0.8319832979224048:121158
Wk @ main.js?0.8319832979224048:121313
Pk @ main.js?0.8319832979224048:121311
Gk @ main.js?0.8319832979224048:121300
performWorkUntilDeadline @ main.js?0.8319832979224048:121652

If the sections containing 127.0.0.1 are removed from theclient.yml, synchronization functions normally.

---

I believe there are two issues here:

First, the description of the "EXTERNAL_LISTEN_HOSTS" is misleading. It is not a parameter for configuring the server to listen on a specific port in the traditional sense; rather, it is used to inform the client of the server address. The variable name is ambiguous.

Second, the description only mentions adding the "HOSTS" parameter but does not specify how to adjust the "HOST" parameter. Regardless, this ultimately leads to the generated configuration file containing the "127.0.0.1" field, causing synchronization failure for the client.

I am not a Docker expert nor deeply familiar with this project's code, but I suspect other users may have encountered this issue, possibly related to #148 .

Expected Behavior

1. Update the description in Configuration to more precisely explain how to configure EXTERNAL_LISTEN_HOSTS and EXTERNAL_LISTEN_HOST.

2. If possible, rename the EXTERNAL_LISTEN_HOSTS field to better reflect its purpose, as it is not truly about external listening.

3. Consider adjusting the generation of client.yml to avoid including the "127.0.0.1" field in configurations for third-party servers, which ultimately leads to synchronization issues.

Steps To Reproduce

1. Deploy this on a third party cloud server.
2. Add "EXTERNAL_LISTEN_HOSTS"="Your.Server.IP.Here" to .env.override
3. Use make start command to start compose.
4. Check ./etc/client.yml and see there are "127.0.0.1" inside.
5. Download configure file and load to local client.
6. Try to create a new space.
7. Notice image sync failed. Wait for some time and check the devtool errors info. 500 (Internal Server Error)

Environment

- Cloud Service Provider: Alibaba Cloud
- OS: Ubuntu 24.04
- Any-Sync_DockerCompose Version: 6.4.0

Anything else?

No response

[fb929]

Hi!
"127.0.0.1" is required for a local client, in situation, when we run client on the same "host machine", where any-sync-dockercompose is running.
this is the base usage scenario of this repo - running local tests.
so it is specified in the default configuration.

When the client loads the client.yml configuration file and attempts to create a new space, images fail to synchronize. The developer console shows a 500 error similar to the following:

the unavailability of some addresses is normal; the client should iterate over the hosts in the configuration and select an available one.
this client error should be temporary and retried. although in my opinion there should be no error here at all, just a switch to the next host in the configuration.
I will ask the client team to check this.

[8cher]

Thank you for your reply. Following your guidance, I conducted some additional tests and observed the following behavior:

1. Reset the client state: I deleted the vault in a test account configured with a specific client.yml file.

2. Recreate a new account: After creating a new account and setting up a Space, I noticed that image synchronization was failing. After waiting for a significant amount of time and then attempting image-related operations, a 500 error appeared in the dev console.

3. Log out and log back in with the key: Once I logged out and logged back in using the key, the image sync function began operating normally. The images were successfully synchronized, and no further issues occurred during operations.

I suspect there may be an issue with a function that refreshes the address selection result — or perhaps a function is not loading the latest address selection properly.

I hope this information helps the team identify the issue.