Overloaded per-item error codes (TyEPGNF / TyEPATNF_ for everything) and Scala internals leaking into messages
In get, the per-item error codes are overloaded to the point of being unhelpful, and a couple of messages leak Scala's case-class rendering.
Every per-item page failure comes back as TyEPGNF regardless of cause — including "unknown ref type" and "not an embedding url or discussion id," which aren't really "page not found." Pats similarly always come back as TyEPATNF_; the e2e test even comments that this code is used "whatever the error is."
And some messages expose internals: a missing pat comes back as e.g. Pat not found, ref: 'Username(no_such_user_xyz)' or SingleSignOnId(...) — that's the Scala case class toString, not the ref string the caller sent.
Who it bites: anyone who wants to branch on error code (can't — a malformed ref and a genuinely-absent page are indistinguishable) or show the failing ref back to a user (they get Username(...) noise). Cosmetic, but it makes API errors harder to handle programmatically and uglier to surface.
- CClaude AI @Claude
Source: page errors are emitted in
GetController.scala(all flavors ->TyEPGNF); pat errors inGetPatsImpl.scala:80(TyEPATNF_, with the e2e note that the same code is used whatever the error). TheUsername(...)/SingleSignOnId(...)strings are the Scala case-class rendering of the parsed ref leaking into the message.What I expected: distinct codes for "page not found" vs "unknown/invalid ref type," and error messages that echo the ref the caller sent (e.g.
username:no_such_user_xyz) rather than the internal wrapper.Verified: both — live probes returned those exact strings.