Read the relay's refusal code, not just the HTTP status #36

2026-09-02T00:48:23Z

paulhitt commented

2026-09-02 00:48:23 +00:00

(Migrated from gitlab.com)

Android half of flamenet-relay!11, and it fixes a pre-existing bug along the way.

A 409 is not always a taken handle. The relay answers 409 for a taken handle, an
already-registered email, and — since !11 — a handle too close to an existing one. All
three were reported as "that handle is already taken".

So somebody whose email was already registered was told to pick a different handle.
Doing so cannot work, and nothing would ever have told them why. That bug predates the new
refusals; adding a third meaning to 409 is what made it visible.

400 was worse: every format refusal became "the account service returned 400".

The status is the transport's opinion; the code in the body is the relay's, and it has
always been sent — nothing here ever read it.

Unknown codes still refuse. A relay newer than the app is the normal case, so an
unrecognised code falls back to the status rather than to success. An account the server
never created would be a far worse failure than a vague message.

An unparseable body cannot throw — a proxy returning HTML on a 409 must still be a
refusal, not a crash.

Tests: 5 new in SignupFailureMappingTest, proven able to fail — collapsing 409 back
to a single meaning turns four of them red. All three Android suites pass.

Pairs with flamenet-relay!11 and flamenet-messenger-ios!45. Not deployed, not merged.

Android half of flamenet-relay!11, and it fixes a **pre-existing bug** along the way. **A 409 is not always a taken handle.** The relay answers 409 for a taken handle, an already-registered email, and — since !11 — a handle too close to an existing one. All three were reported as *"that handle is already taken"*. So somebody whose **email** was already registered was told to pick a different handle. Doing so cannot work, and nothing would ever have told them why. That bug predates the new refusals; adding a third meaning to 409 is what made it visible. 400 was worse: every format refusal became *"the account service returned 400"*. The status is the transport's opinion; the `code` in the body is the relay's, and it has always been sent — nothing here ever read it. **Unknown codes still refuse.** A relay newer than the app is the normal case, so an unrecognised code falls back to the status rather than to success. An account the server never created would be a far worse failure than a vague message. **An unparseable body cannot throw** — a proxy returning HTML on a 409 must still be a refusal, not a crash. **Tests:** 5 new in `SignupFailureMappingTest`, proven able to fail — collapsing 409 back to a single meaning turns four of them red. All three Android suites pass. Pairs with flamenet-relay!11 and flamenet-messenger-ios!45. Not deployed, not merged.

paulhitt (Migrated from gitlab.com) merged commit 7958ebd8bb into main

2026-09-02 19:47:05 +00:00

paulhitt commented

2026-09-02 19:47:06 +00:00

(Migrated from gitlab.com)

mentioned in commit 7958ebd8bb

mentioned in commit 7958ebd8bb5d7cc59bf057f3a6aed485944cfe08

paulhitt commented

2026-09-09 19:01:56 +00:00

(Migrated from gitlab.com)

changed the description

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#36