[SYNC] cloud request timed out

[ixi88]

💻 Platform

• Desktop (Linux)
• Desktop (macOS)
• Desktop (Windows)
• Mobile (Android)
• Mobile (iOS)
• Cloud / WebDAV server

ℹ️ Environment

• App Version: 1.2.6
• Install Channel(s): Play Store
• Sync Backend: Self-hosted Cloud server
• OS Version(s): Android [YOUR VERSION]
• Device clocks auto-sync enabled: yes

🧩 What happened?

On Android, the initial automatic sync after starting the app appears to succeed.

However, when I manually press Sync now shortly afterwards, the sync reproducibly fails with:

cloud request timed out

The self-hosted cloud backend itself appears healthy. A direct request to the /v1/data endpoint returns HTTP 200 in about 46 ms with approximately 150 kB of data.

During a failed manual sync, no corresponding /v1/data request appears in the Mindwtr Cloud server log.

The same behavior occurs:

• on Wi-Fi
• on mobile data
• with Tailscale disabled

I also tested ownCloud/WebDAV as an alternative backend. The Android app showed the same timeout behavior. The WebDAV server itself was independently verified to support PROPFIND, PUT, GET, strong ETags, If-Match and If-None-Match correctly.

This suggests that the timeout may occur inside the Android sync client rather than at the backend or network level.

🔄 Reproduction Steps

1. Configure Android Mindwtr with a self-hosted Mindwtr Cloud backend.
2. Force-stop the Android app.
3. Start Mindwtr again.
4. The automatic startup sync appears to complete successfully.
5. Press Sync now manually.
6. The sync fails with cloud request timed out.
7. Force-stop and restart the app again.
8. The first automatic sync again appears to work, while a subsequent manual sync times out.

✅ Expected result

Manual Sync now should complete successfully, just like the automatic sync that runs after starting the app.

📋 Diagnostic data

• App version: 1.2.6
• Platform: Android
• Backend: Self-hosted Mindwtr Cloud
• Cloud endpoint response: HTTP 200, ~46 ms, ~150 kB
• Network: issue reproduces on Wi-Fi and mobile data
• Tailscale: disabled during testing
• Reproducibility: reproducible after a successful startup sync
• Server observation: during the failed manual sync, no /v1/data request reaches the Mindwtr Cloud server

Additional cross-check:

• ownCloud/WebDAV shows the same Android timeout behavior
• WebDAV PROPFIND: successful
• WebDAV PUT: HTTP 201
• WebDAV GET: HTTP 200
• Correct If-Match: HTTP 204
• Incorrect If-Match: HTTP 412
• If-None-Match on existing file: HTTP 412

Approximate test time:
2026-09-02 around 08:20–09:00 CEST (UTC+2)

mindwtr.log

[dongdongbh]

Thanks for the careful report and the log. It shows two different things, and I want to separate them.

1. The sync at 07:00:06 was not a successful startup sync. It was the setup verification for the cloud backend, and it failed on the phone side while installing an attachment: the Android attachment installer reported "Could not publish attachment generation", and the verification ended with "Candidate attachment proof failed for 2086b34c…". That is a bug in the installer's file-publishing step on your device, and I am fixing it (the error will also name the exact OS reason from now on). Did the app show "Sync setup could not be verified" at that point, or did the sync settings say the backend was active?

2. The manual sync at 07:00:14 was still waiting on its first request to the server when the log was exported. The log ends at that read; the "cloud request timed out" line itself is not in it, so I cannot yet see whether the request was refused by the phone before it left or hung on the network. A request to the same server had completed eight seconds earlier, in about half a second. To pin it down, could you send:

• a log that covers a failed manual sync through to the error (Settings > Diagnostics > Debug logging on, tap Sync now, wait for the error, then Share log);
• the Android version and device model;
• what kind of address the cloud URL uses (public hostname, LAN IP, or a Tailscale address), and whether Chrome on the phone can open that URL at the moment the sync fails.

Nothing is lost either way: the phone's local data stays intact, and the failed attachment proof only blocks the setup from being marked verified.

[dongdongbh]

The installer part is fixed on main in 05788f3: when Android refuses the hard link the installer used to publish a downloaded attachment, it now falls back to an exclusive copy with the same guarantees, and the error names the OS reason. That removes the "Candidate attachment proof failed" block on your phone in the next release.

The timeout part still needs the log that covers a failed manual sync through to the error, plus the address type of your cloud URL and whether Chrome on the phone opens it at that moment.

[ixi88]

Hi thank you for this really ultra rapid reply :) And also, thank you very much for this incredible software. I installed it yesterday and started loving it from the first minute. I was for years on MyLifeOrganized, but already moved everything to Mindwtr, as this makes so much more sense...! Regarding the setup verification: Yes, the app showed “Sync setup could not be verified” when the attachment proof failed. The backend was therefore not marked as successfully verified at that point. I also saw the same attachment-proof error later in the web client: `Candidate attachment proof failed for 2086b34c-976e-4c67-bd8b-e384ee918267` Thanks for fixing the Android attachment installer issue on main. For the timeout issue, I will collect a new debug log that covers the full failed manual sync through to the actual `cloud request timed out` error. Environment details: - Android device: Samsung Flip7 - Android version: 16 - Cloud URL type: public hostname - Cloud URL: `https://gtd-sync.katja-und-udo.de` - Tailscale is not required for access - The issue reproduces both on Wi-Fi and on mobile data - The same cloud endpoint is reachable directly and responds very quickly from the server side - Chrome on the phone can open the cloud URL at the time the sync fails I will attach the new log after reproducing the timeout again. It may need a couple of hours, though, I am at work right now and it doesn't look so appreciative if I "play" with my phone/laptop all the time :D Thanks a lot, highly appreciated Best Udo 2. September 2026 12:31, "Dongda Li" ***@***.*** ***@***.******@***.***>)> schrieb: dongdongbh left a comment (dongdongbh/Mindwtr#1139) (#1139 (comment)) The installer part is fixed on main in 05788f3 (05788f3): when Android refuses the hard link the installer used to publish a downloaded attachment, it now falls back to an exclusive copy with the same guarantees, and the error names the OS reason. That removes the "Candidate attachment proof failed" block on your phone in the next release. The timeout part still needs the log that covers a failed manual sync through to the error, plus the address type of your cloud URL and whether Chrome on the phone opens it at that moment. — Reply to this email directly, view it on GitHub (#1139?email_source=notifications&email_token=BGUIG3A4RXADXSSTQHXRF2L5M7ZJDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJQHAYTONJWGU3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5508175656), or unsubscribe (https://github.com/notifications/unsubscribe-auth/BGUIG3BMOYXYBGXDJXTN4O35M7ZJDAVCNFSNUABGKJSXA33TNF2G64TZHMYTCMJRHE3TQMZYGA5US43TOVSTWNJTGIYDQNJVGEYDFILWAI). Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS (https://github.com/notifications/mobile/ios/BGUIG3EKGRVBYVNHVFBJ7OT5M7ZJDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJQHAYTONJWGU3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG) and Android (https://github.com/notifications/mobile/android/BGUIG3ABQUWUNLG7YQUNWIL5M7ZJDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJQHAYTONJWGU3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA). Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[ixi88]

Hi again Not sure if it is of help, but please find attached an extended log file. I simply let it run for a while. Thanks again and all the best /U Am 2. September 2026 12:31:45 MESZ schrieb Dongda Li ***@***.***>:

…

dongdongbh left a comment (dongdongbh/Mindwtr#1139) The installer part is fixed on main in 05788f3: when Android refuses the hard link the installer used to publish a downloaded attachment, it now falls back to an exclusive copy with the same guarantees, and the error names the OS reason. That removes the "Candidate attachment proof failed" block on your phone in the next release. The timeout part still needs the log that covers a failed manual sync through to the error, plus the address type of your cloud URL and whether Chrome on the phone opens it at that moment. -- Reply to this email directly or view it on GitHub: #1139 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[dongdongbh]

The file did not make it: GitHub drops attachments from email replies, so only your text arrived. Could you open the issue page in a browser and drag the log file into a new comment box there? It uploads and links itself. If it is small, pasting it into a comment as text works too.

[ixi88]

Here U go

mindwtr.log