Ask the relay to hold a poll open #136

2026-09-10T12:18:38Z

paulhitt commented

2026-09-10 12:18:38 +00:00

(Migrated from gitlab.com)

The relay has always been willing to hold an inbox request until
something arrives, and the Android client has never asked it to. The
constant naming the hold was declared in MessengerService and read
nowhere, and the comment next to the 500 ms gap already described a
long poll that was not happening.

What that cost, measured against production: two devices sent 1,177
inbox requests in eight minutes, every one of them held open by the
relay for about 30 ms and answered "nothing". Every message and every
call signal waited out the gap to the next poll. Someone had already
noticed the effect on calls and shortened the gap to a second while one
was being set up, which made the polling denser without making the
signal arrive any sooner.

So wait reaches the wire. The signed-in mailbox is asked to hold; a
backup home never is, because two held reads in a row would put a
backup mailbox's latency in front of the one nearly all mail arrives
at. A held request needs longer than the ordinary call timeout, so it
gets a clone of the client with room for the hold.

Both loops now pace on whether the relay held the request rather than
on a fixed gap: a poll that took a while was itself the wait, and the
next one goes straight back out.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

The relay has always been willing to hold an inbox request until something arrives, and the Android client has never asked it to. The constant naming the hold was declared in MessengerService and read nowhere, and the comment next to the 500 ms gap already described a long poll that was not happening. What that cost, measured against production: two devices sent 1,177 inbox requests in eight minutes, every one of them held open by the relay for about 30 ms and answered "nothing". Every message and every call signal waited out the gap to the next poll. Someone had already noticed the effect on calls and shortened the gap to a second while one was being set up, which made the polling denser without making the signal arrive any sooner. So `wait` reaches the wire. The signed-in mailbox is asked to hold; a backup home never is, because two held reads in a row would put a backup mailbox's latency in front of the one nearly all mail arrives at. A held request needs longer than the ordinary call timeout, so it gets a clone of the client with room for the hold. Both loops now pace on whether the relay held the request rather than on a fixed gap: a poll that took a while was itself the wait, and the next one goes straight back out. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

paulhitt commented

2026-09-10 12:18:39 +00:00

(Migrated from gitlab.com)

assigned to @paulhitt

paulhitt commented

2026-09-10 12:18:40 +00:00

(Migrated from gitlab.com)

restored source branch fix/android-long-poll

restored source branch `fix/android-long-poll`

paulhitt commented

2026-09-10 12:39:28 +00:00

(Migrated from gitlab.com)

added 1 commit

a70787e9 - Hand CI the backup vectors it was never given

Compare with previous version

added 1 commit <ul><li>a70787e9 - Hand CI the backup vectors it was never given</li></ul> [Compare with previous version](/paulhitt/flamenet-messenger-android/-/merge_requests/109/diffs?diff_id=2017299228&start_sha=6584d313ca398e05b14e403e613527b126e75ee1)

paulhitt commented

2026-09-10 12:45:00 +00:00

(Migrated from gitlab.com)

mentioned in commit 44c7b512d6

mentioned in commit 44c7b512d64a39a4e83fee9ee5d30319f9889427

paulhitt (Migrated from gitlab.com) merged commit 44c7b512d6 into main

2026-09-10 12:45:00 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#136