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

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:

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:

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).