Skip to content

CONCEPT Cited by 1 source

Error action-taker classification

Definition

Error action-taker classification is a decision framework that classifies each failure mode by who can actually take recovery action on it. Zalando's 2021 error-modeling post frames it as:

"What is an error? It tells us that something is wrong and gives us some information on what action can be taken. We can think of errors as containers of action-ables. When modeling them, we classify them into different groups depending on who can take that action."

(Source: sources/2021-04-12-zalando-modeling-errors-in-graphql)

The framework maps the action-taker to the channel:

Action-taker Channel
Nobody (bug) response.errors, no code
Front-end / Developer response.errors + extensions.code
Customer / end user schema-level Problem type on a union

Two levels of user

The framework relies on a vocabulary split Zalando is careful to establish early in the post:

  • Developer — the front-end engineer writing the UI. They receive the GraphQL response and need a parseable signal to drive branching logic.
  • Customer — the end user of the product. They receive whatever the front-end renders, ideally a localised, human-friendly message near the field that failed.

Errors are modeled for whichever of these two can actually take action.

Worked examples

The post lists four canonical cases and what the framework decides:

Case 1 — Resource Not Found (404)

  • Action-taker: nobody — it's a navigation bug; some service produced an ID that points to a missing resource.
  • Channel: Error with extensions.code = NOT_FOUND.
  • Must propagate (handled by GraphQL's default null-propagation) so the UI can show a "Not Found" page.

Case 2 — Authorization

  • Ostensible action-taker: Customer ("please log in").
  • Actual action-taker: Developer — the UI is what decides whether to show a login dialog inline, navigate to a login view, or redirect. The Customer just sees the UI react.
  • Channel: Error with extensions.code = NOT_AUTHORIZED.

Case 3 — Mutation input validation

  • Action-taker: Customer — only they can fix an invalid email or a weak password.
  • Channel: Problem type in the schema (on a union ...Result = Success | Problem). Translated message in the Problem type; per-field enum for the specific failure.
  • "Mutation Inputs is the only case where it is crucial to construct Problem types."

Case 4 — Internal Server Error / runtime exception

  • Action-taker: nobody at request time; operator to fix the bug.
  • Channel: Error, no code. Front-end treats all non-coded errors uniformly — retry with backoff, or show a generic error page.

Why the framework matters

Without this decision rule teams tend to either under-model errors (everything in response.errors with a generic message, leading to string parsing) or over-model them (every failure mode as a Problem type on every field, destroying GraphQL's query-shape ergonomics). The action-taker question is the cheapest discriminator that routes each failure mode to the right channel.

Seen in

Last updated · 476 distilled / 1,218 read