Expand description
Error response envelopes.
Parse has three different error bodies, and they are not interchangeable. Getting this
wrong is invisible in a browser and breaks SDKs, because clients branch on the presence of
code and read error rather than message.
| Source | Status | Body |
|---|---|---|
A Parse.Error | 400, or 404 for OBJECT_NOT_FOUND, or 500 for INTERNAL_SERVER_ERROR | {"code":N,"error":"..."} |
| An HTTP-level rejection | as given, e.g. 403 | {"error":"..."} with no code |
| Anything else thrown | 500 | {"code":1,"message":"Internal server error."}, key message |
Upstream: handleParseErrors (middlewares.js:596-646), which branches on the type of the
thrown value in that order. The code-less shape comes from the err.status && err.message
branch at :629-631; the third from the else at :635-644.
The third row is the reason parse_rust_core::ErrorOrigin exists. It is not “code 1”: a
Parse.Error deliberately carrying INTERNAL_SERVER_ERROR is row one and keeps its message,
and there are several of those upstream. Branching on the code instead of on the origin would
blank out those messages, which is a worse defect than the disclosure it would be fixing.
Structs§
- Http
Error - An HTTP-level rejection: a status and a message, with no Parse error code.
- Parse
Error Response - A failure raised by a route, rendered as whichever of the two
code-carrying bodies it is.
Constants§
- INTERNAL_
SERVER_ ERROR_ MESSAGE - The whole of the generic 500 body’s message (
middlewares.js:640). Note the trailing period.