bug: Sliding sync traffic is unholy when a list range shrinks and grows #2220

New issue

Closed

opened 2026-09-10 12:25:30 +00:00 by GlitchedAxiom · 0 comments

GlitchedAxiom commented

2026-09-10 12:25:30 +00:00

What is the bug?

Yesterday i found out, my Element X on Android is responsible for ~30gb+ of traffic per month which is WAY to much.

The SDK debug logs (of 50 min, 47 pushes) show the room-list connection receiving 210 MB in 333 responses, 37 of them 1-11 MB, while pos stays continuous the whole time. After every push the server sends almost every joined room again with initial: true, full required_state and timeline.

On every sync restart the SDK first requests the list with range [0, 19], then grows it to [0, 99] on the same connection. Continuwuity resets the stored position of every room outside the current ranges to 0 and treats them as never sent.

Its expected when a range grows, only rooms not sent before or with updates since are returned. The stored position should be kept (per connection!). This behaviour is explained in the MSC itself as a Common pattern: https://github.com/matrix-org/matrix-spec-proposals/blob/erikj/sss/proposals/4186-simplified-sliding-sync.md#paginating-room-list

Here is some data from the debug logs - look at the sync restarts and the room-list response size:

Metric	Value
Window	2026-09-10T07:00:50 – 2026-09-10T07:51:07 (50 min)
Downloaded	216.3 MB (uploaded 491.2 KB)
Pushes	47
Sync restarts	37
Median session	13 s
Room-list	333 responses, 209.9 MB total, largest 5.7 MB, 37 responses >= 1 MB (207.6 MB), 0 fresh connections (no pos)

By endpoint:

Count	Received	Sent	Conn	Endpoint
333	209.9 MB	432.9 KB	room-list	`POST /sync` [200]
44	4.0 MB	37.8 KB	notifications	`POST /sync` [200]
129	2.3 MB	6.6 KB	encryption	`POST /v3/keys/query` [200]
1	81.0 KB	0 B	–	`GET /v1/media/download/matrix.org/iJluFBsmAZTbyJjxXZjGtxeZ` [200]
129	24.6 KB	14.0 KB	encryption	`POST /sync` [200]
1	1.1 KB	0 B	notifications	`GET /v1/auth_metadata` [200]

Steps to reproduce

Use Element X on Android
Look into the debug logs

Server name and version

v26.8.1

Additional context

This is the first and biggest issue i found while digging the Element X debug logs. There will probably be more. Element X and Continuwuity are responsible for eating a big chunk of my mobile data traffic :c

### What is the bug? Yesterday i found out, my Element X on Android is responsible for ~30gb+ of traffic per month which is WAY to much. The SDK debug logs (of 50 min, 47 pushes) show the room-list connection receiving 210 MB in 333 responses, 37 of them 1-11 MB, while `pos` stays continuous the whole time. After every push the server sends almost every joined room again with `initial: true`, full `required_state` and timeline. On every sync restart the SDK first requests the list with range `[0, 19]`, then grows it to `[0, 99]` on the same connection. Continuwuity resets the stored position of every room outside the current ranges to 0 and treats them as never sent. Its expected when a range grows, only rooms not sent before or with updates since are returned. The stored position should be kept (per connection!). This behaviour is explained in the MSC itself as a Common pattern: https://github.com/matrix-org/matrix-spec-proposals/blob/erikj/sss/proposals/4186-simplified-sliding-sync.md#paginating-room-list Here is some data from the debug logs - look at the sync restarts and the room-list response size: | Metric | Value | |---|---| | Window | 2026-09-10T07:00:50 – 2026-09-10T07:51:07 (50 min) | | Downloaded | 216.3 MB (uploaded 491.2 KB) | | Pushes | 47 | | Sync restarts | 37 | | Median session | 13 s | | Room-list | 333 responses, 209.9 MB total, largest 5.7 MB, 37 responses >= 1 MB (207.6 MB), 0 fresh connections (no pos) | By endpoint: | Count | Received | Sent | Conn | Endpoint | |---:|---:|---:|---|---| | 333 | 209.9 MB | 432.9 KB | room-list | `POST /sync` [200] | | 44 | 4.0 MB | 37.8 KB | notifications | `POST /sync` [200] | | 129 | 2.3 MB | 6.6 KB | encryption | `POST /v3/keys/query` [200] | | 1 | 81.0 KB | 0 B | – | `GET /v1/media/download/matrix.org/iJluFBsmAZTbyJjxXZjGtxeZ` [200] | | 129 | 24.6 KB | 14.0 KB | encryption | `POST /sync` [200] | | 1 | 1.1 KB | 0 B | notifications | `GET /v1/auth_metadata` [200] | ### Steps to reproduce 1. Use Element X on Android 2. Look into the debug logs ### Server name and version v26.8.1 ### Additional context This is the first and biggest issue i found while digging the Element X debug logs. There will probably be more. Element X and Continuwuity are responsible for eating a big chunk of my mobile data traffic :c

GlitchedAxiom added the

Bug

Status

Needs Investigation

labels

2026-09-10 12:25:30 +00:00