Make important failures stand out
Wildo classifies handled errors so routine client conditions do not look like server outages. The boundary that handles a failure owns its log entry, with structured fields and a stack when the level warrants one.
That keeps expected refusals visible without drowning operational faults in repeated exception messages.
Example — Distinguish an expired session from an outage
An expired access token that the client can refresh is logged at debug. A failed authorization is a warning. A server fault is an error with a stack, making the situations easier to separate during investigation.
For engineers
Read severity as an operating signal
The classifier combines the error’s declared status and severity, with a narrow exception for transparent client recovery:
| Condition | Emitted level | Stack in classified boundary log |
|---|---|---|
| Recognized self-healing expired JWT | Debug | No |
| Client condition with low severity | Debug | No |
| Client condition with medium severity | Warn | No |
| Server status or higher severity | Error | Yes |
A bad token signature and an edit conflict are not transparent recovery cases. A queue boundary can deliberately use its own operational level while reusing the canonical error-field projection: a dead-lettered job remains important regardless of the underlying request-shaped classification.
Emit at the handling boundary
This source excerpt from the classified logging helper shows the shared fields and conditional stack. The caller supplies the boundary-specific context:
const level = classifyBackendErrorLogSeverity(error);
const mergedContext: Record<string, unknown> = {
...projectWildoBackendErrorLogFields(error),
...context,
};
const finalContext: Record<string, unknown> =
backendErrorLogSeverityIncludesStack(level) && typeof error.stack === 'string'
? { ...mergedContext, stack: error.stack }
: mergedContext;
The helper then dispatches once to the logger method corresponding to level. Error construction emits no log; application services should propagate request errors to their existing boundary instead of logging the same failure at every layer.
Keep swallowed faults visible too
For best-effort catches that handle rather than propagate a classified Wildo backend error, projectCaughtErrorLogFields(error) carries a severity floor. LoggerService can raise a requested debug/info/warn record to that floor and records promotedFromLevel. A classified Wildo server fault therefore does not disappear into warn merely because the caller expected the ordinary case to be non-fatal. Native errors and other unknown values retain structured diagnostic detail but do not acquire this classifier-derived floor; the caller must select their appropriate level.
The floor applies through that projection/logger path; it is not global interception of every console write. Classification also does not create monitoring rules or increment a production alert counter. Configure the receiving system’s queries and policies around the actual records it receives.