[QA] §C Upload retry on a flaky network (best-effort) #172

New Issue

2026-09-17T23:24:06-04:00

jared commented

2026-09-17 23:24:06 -04:00

Migrated from LOTUS_TESTING.md §C on 2026-09-17 — the file is now reference-only.

How to report: tick each item as it passes; on FAIL comment with what you saw vs expected, browser/OS, web (chat.lotusguild.org) vs desktop (Tauri), theme, and any browser-console errors. Screenshots for anything visual.

Checklist

C2. Upload retry on flaky network (best-effort)

C2. Upload retry on flaky network (best-effort)

In devtools → Network, set a throttle that drops/slows requests, or toggle Offline briefly during a file upload.
Expected

A transient failure retries (up to 3×, with backoff) and the upload can still succeed once the network recovers.
A genuine, permanent rejection (e.g. file too large / 4xx) still fails fast with the usual error — it should not spin retrying.

_Migrated from `LOTUS_TESTING.md` §C on 2026-09-17 — the file is now reference-only._ **How to report:** tick each item as it passes; on FAIL comment with what you saw vs expected, browser/OS, web (chat.lotusguild.org) vs desktop (Tauri), theme, and any browser-console errors. Screenshots for anything visual. **Checklist** - [ ] C2. Upload retry on flaky network (best-effort) --- ### C2. Upload retry on flaky network (best-effort) 1. In devtools → Network, set a throttle that drops/slows requests, or toggle Offline briefly **during** a file upload. **Expected** - A transient failure **retries** (up to 3×, with backoff) and the upload can still succeed once the network recovers. - A genuine, permanent rejection (e.g. file too large / 4xx) still **fails fast** with the usual error — it should **not** spin retrying.

jared added this to the Manual QA backlog milestone 2026-09-17 23:24:06 -04:00

jared added the area: media qa labels 2026-09-17 23:24:06 -04:00

jared referenced this issue

2026-09-18 17:58:17 -04:00

Upload error card shows the raw MatrixError string including the server URL #213

jared commented

2026-09-18 17:58:17 -04:00

Tested on the local dev homeserver with Playwright, routing /_matrix/media/v3/upload per attempt. Found a real bug, fixed in the next commit on lotus.

Before the fix:

scenario	requests	result
502 → connection dropped → ok	2	gave up after the dropped connection: Retry button, upload never completed
permanent 413	1	fails fast ✓
persistent 503	4 (1 s, 2 s, 4 s back-off)	gives up after max retries ✓

Cause: matrix-js-sdk rejects any upload whose XHR ends with status 0 (offline, reset, DNS) with DOMException('AbortError') "to mimic fetch" — the same error name mx.cancelUpload() produces. isRetryableUploadError treated every AbortError as a user cancel, so the exact failure class the retry loop was written for (C2: "toggle Offline briefly during an upload") was never retried. Now the decision uses our own cancel AbortSignal.

After the fix: 502 → drop → ok completes in 3 attempts (gaps 1 s, 2 s), the image sends; 413 still 1 attempt; 503 still 4. Unit-tested (utils/uploadRetry.test.ts: dropped connection retried, user cancel not retried, 5xx retried / 4xx fast-fail).

Cosmetic follow-up filed as #213: the permanent-failure card prints the raw MatrixError: [413] nope (http://…/upload?filename=…) string. Closing.

Tested on the local dev homeserver with Playwright, routing `/_matrix/media/v3/upload` per attempt. **Found a real bug, fixed in the next commit on `lotus`.** Before the fix: | scenario | requests | result | |---|---|---| | 502 → connection dropped → ok | **2** | gave up after the dropped connection: Retry button, upload never completed | | permanent 413 | 1 | fails fast ✓ | | persistent 503 | 4 (1 s, 2 s, 4 s back-off) | gives up after max retries ✓ | Cause: matrix-js-sdk rejects any upload whose XHR ends with status 0 (offline, reset, DNS) with `DOMException('AbortError')` "to mimic fetch" — the **same** error name `mx.cancelUpload()` produces. `isRetryableUploadError` treated every AbortError as a user cancel, so the exact failure class the retry loop was written for (C2: "toggle Offline briefly during an upload") was never retried. Now the decision uses our own cancel `AbortSignal`. After the fix: 502 → drop → ok completes in **3** attempts (gaps 1 s, 2 s), the image sends; 413 still 1 attempt; 503 still 4. Unit-tested (`utils/uploadRetry.test.ts`: dropped connection retried, user cancel not retried, 5xx retried / 4xx fast-fail). Cosmetic follow-up filed as #213: the permanent-failure card prints the raw `MatrixError: [413] nope (http://…/upload?filename=…)` string. Closing.

jared closed this issue

2026-09-18 17:58:18 -04:00

jared referenced this issue from a commit

2026-09-18 18:01:17 -04:00

fix(upload): retry on dropped connections — the SDK reports XHR network failures as AbortError, which we treated as a user cancel (#172)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: LotusGuild/cinny#172