You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Error handling in Graph Explorer is a set of independent decisions rather than a system. Each domain error rolls its own shape, utils/createDisplayError.ts grew a ~190-line if-chain that silently degrades to "Something went wrong" when a case is missed, connector boundaries hand back unchecked casts, and untrusted imported files can throw from inside a component and leave the app broken across reloads. Tests assert errors three different ways and the guidance in docs/agents/testing.md no longer matches any of them.
None of these is large alone. Together they are why a new error type costs a hand-written branch in two display helpers, why a 403 shows an opaque JSON blob, and why a bad color in a shared styling file is unrecoverable.
This initiative gathers the existing backlog so the pieces get decided together instead of one PR at a time. It is a container: track its children, not this issue.
Themes
Error modelling and contract — one shape for domain errors, so the display and details paths stop needing a branch per type.
Several children are older backlog items with no recent activity (#359, #891, #1210, #1214, #1287, #1635, #1767). They are in scope but worth confirming as still wanted before being picked up. Most also carry no audience label.
Deliberately excluded, for the record: #1045 (proxy retry env vars, config knobs rather than error-handling design), #1217 (diagnostic context for all queries, not failures), #1209 (connection detail UI enhancement), #2060 and #1557 (domain logic and render-ordering bugs that merely manifest as messages), #1327 (ordinary form validation).
Important
Internal only — this issue is maintained by the core team and is not accepting external contributions.
Description
Error handling in Graph Explorer is a set of independent decisions rather than a system. Each domain error rolls its own shape,
utils/createDisplayError.tsgrew a ~190-lineif-chain that silently degrades to "Something went wrong" when a case is missed, connector boundaries hand back unchecked casts, and untrusted imported files can throw from inside a component and leave the app broken across reloads. Tests assert errors three different ways and the guidance indocs/agents/testing.mdno longer matches any of them.None of these is large alone. Together they are why a new error type costs a hand-written branch in two display helpers, why a 403 shows an opaque JSON blob, and why a bad color in a shared styling file is unrecoverable.
This initiative gathers the existing backlog so the pieces get decided together instead of one PR at a time. It is a container: track its children, not this issue.
Themes
Error modelling and contract — one shape for domain errors, so the display and details paths stop needing a branch per type.
isErrorResponseguard with Zod validationValidation at boundaries — Zod where untrusted data enters: connector responses, imported styling and connection files, user-entered limits.
User-facing messaging — what a user actually reads when something fails, and getting notifications out of React-only code paths.
Recovery and retry — surviving a failure rather than blanking the app, and retrying at the right granularity.
Diagnostics — enough context logged to explain a failure after the fact.
Testing conventions — one documented way to assert errors, derived from whatever base type the modelling work lands on.
Notes
Several children are older backlog items with no recent activity (#359, #891, #1210, #1214, #1287, #1635, #1767). They are in scope but worth confirming as still wanted before being picked up. Most also carry no audience label.
#1850 was closed as already delivered by #2162.
Deliberately excluded, for the record: #1045 (proxy retry env vars, config knobs rather than error-handling design), #1217 (diagnostic context for all queries, not failures), #1209 (connection detail UI enhancement), #2060 and #1557 (domain logic and render-ordering bugs that merely manifest as messages), #1327 (ordinary form validation).
Important
Internal only — this issue is maintained by the core team and is not accepting external contributions.