Common utilities for error handling within Backstage with structured error classes and serialization functions
63
Pending
Does it follow best practices?
Impact
63%
1.28xAverage score across 10 eval scenarios
Pending
The risk profile of this skill
{
"context": "Evaluates whether the solution uses @backstage/errors to turn failed fetch responses into structured ResponseError instances with parsed error bodies and HTTP metadata. Checks focus on calling the provided builders and preserving the fields they supply rather than reimplementing parsing or custom error shapes.",
"type": "weighted_checklist",
"checklist": [
{
"name": "ResponseError usage",
"description": "Non-ok responses are passed to `ResponseError.fromResponse` (or the equivalent builder) instead of custom error parsing or generic throws.",
"max_score": 40
},
{
"name": "Status metadata",
"description": "The thrown `ResponseError` preserves package-provided fields like `statusCode`, `statusText`, and stored `response`/`body` data for inspection after failures.",
"max_score": 25
},
{
"name": "Error body & cause",
"description": "Parsed `body.error` from the package is exposed, and the remote error is surfaced through `ResponseError.cause` (checking name/message) rather than being replaced or dropped.",
"max_score": 20
},
{
"name": "Fallback parsing",
"description": "Non-JSON failures still rely on `ResponseError`/`parseErrorResponseBody` behavior so the raw error text is reflected in `body.error.message` while the HTTP status code is retained.",
"max_score": 15
}
]
}evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10