[BUG]Android WebDAV sync fails: mutation fence response exceeds 4096 byte download limit

[Toxican]

Android WebDAV sync fails: mutation fence response exceeds 4096 byte download limit

If this is mainly a sync/data integrity problem, please use the Sync / Data Issue template for faster triage.

💻 Platform

• Desktop (Linux - Arch/Hyprland/Niri/Other)
• Desktop (macOS)
• Desktop (Windows)
• Mobile (Android)
• Mobile (iOS)

🧭 Affected Area

• Sync / data consistency
• UI / interaction
• Projects / areas / sections
• Search / filter
• Settings / preferences
• Notifications / reminders
• Recurrence / calendar
• Attachments
• Audio / transcription
• Other

ℹ️ Environment

• App Version: v1.2.5 (Desktop and Android)
• Install Channel: Android: Play Store
• OS Version: Android 16; Desktop: Arch Linux
• Device: Android phone
• Sync Backend: WebDAV
• WebDAV Provider: mailbox.org (Open-Xchange WebDAV)

🚨 Impact

• Blocks core workflow
• Data loss or data mismatch
• Crash / freeze
• Visual issue only

📝 Description

WebDAV sync works correctly with Mindwtr Desktop v1.2.5, but fails on Android v1.2.5 when using the same WebDAV server and remote data.json.

The WebDAV connection test on Android succeeds, but attempting an actual sync fails immediately. The Android app continues to show "Never synced".

Debug logging reports:

Remote sync mutation fence acquisition failed: Response exceeds the 4096 byte download limit

The remote data.json is currently 20,860 bytes.

The WebDAV server itself appears to behave correctly. A normal GET returns the complete file with HTTP 200, and a manually tested 4096-byte HTTP Range request returns exactly 4096 bytes with HTTP 206.

🔄 Steps to Reproduce (REQUIRED)

1. Configure a mailbox.org WebDAV directory as the sync backend in Mindwtr Desktop v1.2.5.
2. Sync successfully from Desktop, creating/updating data.json on the WebDAV server.
3. Configure the same WebDAV directory and credentials in Mindwtr Android v1.2.5.
4. Test the WebDAV connection on Android. The connection test succeeds.
5. Start Sync on Android.
6. Sync fails and the app remains at "Never synced".
7. Enable debug logging and repeat the sync.
8. The log reports:

Remote sync mutation fence acquisition failed: Response exceeds the 4096 byte download limit

The same problem also occurs when using a dedicated WebDAV subdirectory containing only the Mindwtr sync data.

🎯 Expected Behavior

Mindwtr Android should successfully synchronize the same WebDAV data.json that Mindwtr Desktop v1.2.5 can synchronize.

A remote data.json larger than 4096 bytes should not cause mutation fence acquisition to fail.

🧪 Regression?

• This worked in a previous version
• Last known working version (if known): Unknown

📸 Screenshots / Logs

Relevant Android debug log:

{"ts":"2026-09-01T06:39:45.125Z","level":"info","scope":"sync","message":"Sync start","context":{"backend":"webdav"}}
{"ts":"2026-09-01T06:39:45.125Z","level":"info","scope":"sync","message":"Sync diagnostic start","context":{"backend":"webdav"}}
{"ts":"2026-09-01T06:39:45.126Z","level":"info","scope":"sync","message":"Sync step","context":{"step":"flush","sinceLastStepMs":"0"}}
{"ts":"2026-09-01T06:39:45.126Z","level":"info","scope":"sync","message":"Sync step","context":{"step":"setup","sinceLastStepMs":"0"}}
{"ts":"2026-09-01T06:39:45.131Z","level":"info","scope":"sync","message":"Sync step","context":{"step":"read-local","sinceLastStepMs":"5"}}
{"ts":"2026-09-01T06:39:45.149Z","level":"info","scope":"sync","message":"Sync local reconcile","context":{"reconcile":"aligned-skip","durationMs":"1","tasks":"9"}}
{"ts":"2026-09-01T06:39:45.152Z","level":"info","scope":"sync","message":"Sync step","context":{"step":"read-remote","sinceLastStepMs":"21"}}
{"ts":"2026-09-01T06:39:45.296Z","level":"warn","scope":"sync","message":"Sync failed","context":{"error":"Remote sync mutation fence acquisition failed: Response exceeds the 4096 byte download limit"}}

WebDAV GET test

A normal GET of the remote data.json returns:

HTTP/2 200
x-powered-by: Open-Xchange
content-disposition: attachment
etag: "9965763-46-2-1788242672016"
accept-ranges: bytes
content-type: application/json
content-length: 20860

Downloaded file size:

20860 /tmp/get-data.json

HTTP Range test

I also tested a 4096-byte Range request against the same resource:

Range: bytes=0-4095

The WebDAV server responds:

HTTP/2 206
etag: "9965763-46-2-1788242672016"
accept-ranges: bytes
content-type: application/json
content-length: 4096

The resulting response body is exactly 4096 bytes:

4096 /tmp/range-data.bin

A WebDAV PROPFIND also succeeds with HTTP 207 Multi-Status, reports the correct data.json size and provides an ETag.

Mindwtr Desktop v1.2.5 successfully syncs against this same WebDAV endpoint.

This suggests that the Android WebDAV mutation-fence code may be applying the 4096-byte response limit to the remote data resource, or otherwise attempting to read more than the allowed mutation-fence response size.

2. Toggle Debug logging to ON.
3. Reproduce the issue.
4. Tap Share log to export the file and attach it here.

Note: Logs are local-only and redact common credentials.

📋 Additional Context

Add any other context about the problem here.

[dongdongbh]

Fixed with f24d80a.

Before some sync steps the app reads a small reservation file so two devices cannot change the same folder at once. mailbox.org answers the request for that missing file with a page bigger than the app allows that file to be, and sync stopped right there. We hit the same server behavior with Koofr last week; such a response now reads as "no such file" and sync proceeds, with the two-device protection unchanged. Your Range test was sound, the limit was on our side of the read, not the server's.

Please test the next release and let us know if Android syncs then.

[dongdongbh]

Correction, with a better fix: 9a25f68.

mailbox.org was innocent. On Android the address of the reservation file resolved to data.json itself, so the app tried to read your 20,860-byte document as the tiny reservation record and hit the size limit. That is why the same server worked from desktop. The address derivation is fixed on both phone platforms; the earlier change alone would not have helped your case.

Please test with the next release.

[Toxican]

Thanks! I tested the new release and can confirm that the original issue is fixed.

The Android client can now successfully sync with mailbox.org/WebDAV on a fresh setup. So the 4096 byte download limit issue is gone. 👍

However, I’m now seeing a different issue when using my already configured sync with my existing Mindwtr data.

After setting up WebDAV and syncing the existing data, Mindwtr reports:

Another device is currently syncing

and refuses to sync.

Sync between 2 Desktop clients works flawless, only the Andriod device refuses.

As far as I can tell, there is no other Mindwtr instance syncing at that time. I made sure the desktop client was not running while Android sync tested.

A few additional observations:

• Fresh Android setup → WebDAV sync works
• Existing WebDAV sync with my current data → reports that another device is syncing
• No other Mindwtr instance is active
• The WebDAV directory contains only data.json
• There is no separate reservation/lock file visible in the WebDAV directory
• I also checked the WebDAV state with PROPFIND
• Both the Mindwtr directory and data.json return an empty <D:lockdiscovery />, so there is no active WebDAV lock

So mailbox.org does not appear to be holding an actual WebDAV lock.

Since this appeared after the reservation-file fix, I suspect there may still be an issue with the reservation/mutation-fence state when an existing sync is used — for example a stale reservation or the reservation state not being cleared/detected correctly.

I can provide the Android debug log, the PROPFIND response, or test specific scenarios if that would help.

But the good news first: the original Android/mailbox.org issue is definitely fixed. Thanks for the quick fix!

[dongdongbh]

Good to hear the size-limit failure is gone, thanks for testing.

The follow-up is not a stale reservation. 1.2.6 still carries the #1132 address bug on phones: Android derives the reservation file's address as data.json itself. With your existing document there, the app reads your 20 KB data.json where the tiny reservation record should be, then tries a create-only write at that same address; the server refuses to overwrite data.json, and after a few attempts the app reports another device holding the location. A fresh folder has no data.json yet, so nothing collides, which is exactly your fresh-works, existing-fails split. Desktop derives the address correctly and never hits this.

Fixed with 9a25f68, which landed after 1.2.6 was cut. Your folder needs no cleanup. Please test Android once the next release is out.

[7thgenerationdesign]

@dongdongbh thanks for the fix on this. Can you please give me an idea of timeline for patched release? I added quite a few tasks to my mobile which is now out of sync with desktop, and am trying to figure out how to proceed.

[dongdongbh]

@7thgenerationdesign An emergency release goes out today with the phone-side fix.

How to proceed meanwhile: keep using the phone as you are; the tasks you added there are safe in its local database, and the desktop can keep syncing on its own. Once the phone has the update, run one sync on it: the merge keeps the edits from both sides, so nothing on the desktop is overwritten and nothing on the phone is lost. Until then, there is no benefit in retrying the Android sync, so leave it alone.