Common utilities for error handling within Backstage with structured error classes and serialization functions
63
{
"context": "Evaluates how the solution leverages @backstage/errors to build a tolerant parser for failed HTTP responses. Scoring checks that parsing and fallbacks rely on the package's response body utilities and that the parsed error data is preserved rather than reimplemented.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Delegate parsing",
"description": "Uses @backstage/errors parseErrorResponseBody (or ResponseError.fromResponse when a Response is available) instead of custom JSON/text branching to interpret consumed error responses.",
"max_score": 35
},
{
"name": "Content-type aware",
"description": "Passes status, statusText, headers, and consumed body text so package parsing logic can honor application/json detection and avoids manual parsing that bypasses package guards.",
"max_score": 20
},
{
"name": "Fallback retention",
"description": "Preserves package-provided responseText or fallback body when JSON is missing/invalid and does not throw on parse failures, reflecting the tolerant behavior of parseErrorResponseBody.",
"max_score": 15
},
{
"name": "Error fidelity",
"description": "Returns the parsed error object (message/name/stack/cause) exactly as produced by @backstage/errors deserialization instead of reshaping or dropping fields.",
"max_score": 15
},
{
"name": "Response metadata",
"description": "Propagates package-parsed status information and any response metadata (e.g., response payload) into the result rather than substituting custom values.",
"max_score": 15
}
]
}Install with Tessl CLI
npx tessl i tessl/npm-backstage--errorsevals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10