upstream: a profile location can be set through the API but never cleared

[Adron]

Found while probing #57 on 2026-09-15. A profile location can be set through the API and cannot be removed through it.

Evidence

PATCH /api/user/update is the only user-mutation route (OPTIONS /api/user → GET, HEAD, OPTIONS; there is no /api/user/location, /api/user/profile or /api/user/settings). Setting works:

PATCH /api/user/update {"latitude":47.6062,"longitude":-122.3321}
→ 200 {"message":"User updated successfully", …}
GET /api/user → "latitude":47.6062,"longitude":-122.3321

Every form of unset is refused:

Body	Result
{"latitude":null,"longitude":null}	400 latitude must be a number between -90 and 90
{"latitude":"","longitude":""}	400 same
{"latitude":"null","longitude":"null"}	400 same
{"latitude":false,"longitude":false}	400 same
{"latitude":-999,"longitude":-999}	400 same

And every speculative "clear" key is accepted-and-ignored — a 200 that changes nothing, which is the worst of both worlds for a caller trying to honour a deletion:

Body	Result
{"clearLocation":true}	200, coordinates unchanged
{"clearLocation":"true"}	200, coordinates unchanged
{"location":null}	200, coordinates unchanged
{"cleared":true}	200, coordinates unchanged

DELETE /api/user/location → 404.

The cleared field is not what #57 guessed

#57 inferred that UserDTO.cleared was the clear signal, on the strength of the test account reading "cleared":true with null coordinates. That was correlation, not mechanism: setting a location leaves cleared at true, and writing cleared:true does not clear the location.

In the live OpenAPI, cleared sits among spamScore, spamReasons, signupIp, signupUserAgent, signupReferrer — it reads as a moderation/anti-spam field that happens to share a name with what a location-clearing flag would be called.

Recording that explicitly so the next sweep does not re-derive the same wrong inference.

Why this is more than an inconvenience

The coordinates are published on a public profile. A field that can be set and not unset is a privacy defect, not a missing feature: a user who publishes an approximate home location has no way to take it back.

/help/settings documents the field as "Optional location for your profile" and describes no clear action — so this is not a macOS gap. The web appears not to offer one either.

What this blocks

#57 cannot ship its setter. Shipping set-without-clear would make the privacy problem strictly worse: macOS would become a way to publish a location that cannot be removed from anywhere. #57 is re-scoped to the read-only half — showing a location set elsewhere, so it is at least visible — with set and clear landing together once this exists.

The ask

Either:

1. Accept null for latitude/longitude on PATCH /api/user/update and treat the pair as cleared, or
2. add DELETE /api/user/location, or
3. name whatever mechanism the web uses, if one exists and this probe missed it.

Whichever it is, the client needs it to be a documented shape rather than a guess — a wrong clear payload that returns 200 and changes nothing is exactly the failure that leaves a location published while the user believes it was removed.

Note on the test account

This probe left a location set on the .env contract-test account (messenger, 47.6062 / −122.3321) because it could not be undone. That is not a side effect of carelessness — it is the bug, reproduced. It needs clearing by whatever out-of-band means exists (direct database access, or the mechanism this issue is asking for).

[Adron]

Ready for the backend — everything the ask needs is in the issue body

No further client work is possible here and none should be attempted: this is a route that does not exist.

Recap of what blocks what

• feat(settings): profile location - show, set and clear latitude/longitude - G36 #57's setter is blocked on this. Shipping "set" without "clear" would make macOS a way to publish an approximate home location on a public profile that the user can never take back. feat(settings): profile location - show, set and clear latitude/longitude - G36 #57 is re-scoped to the read-only half and that half has shipped in PR feat(settings): Profile settings — display name, bio, avatar, theme and the message cap (G34) #92 — a location set elsewhere is now visible on the Mac, with the reason it cannot be removed stated in the pane and linked here.
• Nothing else depends on it.

What we need from you

One of the three options in the issue body, decided by whoever owns the API:

1. accept null for latitude/longitude on PATCH /api/user/update and treat the pair as cleared, or
2. add DELETE /api/user/location, or
3. name the mechanism the web uses, if one exists and this probe missed it.

Option 3 is worth checking first and costs nothing: if the web's settings page has a working Clear button, watching what it sends settles this in a minute.

⚠️ Standing consequence on the test account

The probe set a location it could not remove on the .env contract-test account (messenger, 47.6062 / −122.3321) — Seattle. That is the bug reproduced rather than carelessness, and it is the most direct demonstration of why this matters: a probe that tried every documented and undocumented way to undo a write could not.

It is published on that account's public profile until one of the three options above exists, or until someone clears it directly in the database. Worth doing whichever is quicker, since it is a real account.