Blog: Clearer Error Feedback — Network Errors & Silent Form Failures (ERR-17)
Clearer Error Feedback: Network Errors & Silent Form Failures
Release: v0.1.130 · Control: ERR-17
Small UX details matter in compliance tooling. When a form fails, users need to know why — and they shouldn't lose their work in the process. This release fixes two distinct failure modes that were undermining that principle.
The Problem
1. Network errors looked like validation errors
On the Add New Person form, if a network error occurred during submission, the error message was attached directly to the fullName field — the same mechanism used for validation messages like "Name is required" or "Name is too long".
From a user's perspective, this was confusing. A message appearing beneath a specific field implies that field is the source of the problem. A network error is not caused by the user's input, and presenting it that way could lead users to edit correct data unnecessarily, or simply not understand why their submission failed.
Field values were already preserved on error (no data loss), but the communication wasn't clear enough.
2. API key creation failed silently
On the Settings page, if the API key creation request failed for any reason, the handleCreateKey handler would complete without showing any feedback at all. The form would simply return to its default state, leaving the user with no confirmation of failure. This is particularly problematic in a compliance context where users need certainty about whether an action succeeded.
What's Fixed
Dismissible top-level alert for network errors
Network and server errors in the Add New Person form are now separated from field-level validation errors. When a non-validation error occurs:
- A dismissible alert banner is rendered above the form fields
- The alert clearly communicates a network or server issue, not a data problem
- All previously entered field values remain intact — no re-entry required
- Field-level error indicators are reserved exclusively for validation feedback
This distinction follows a standard UX pattern: field errors point to specific input problems; form-level alerts communicate systemic or transient failures.
Explicit failure feedback on API key creation
The API key creation form on the Settings page now captures error state when the creation request fails. Users will see inline failure feedback rather than a silent no-op, making it clear that a retry or investigation is needed.
Why It Matters
In a sanctions screening platform, ambiguity around form state is more than a minor inconvenience. Compliance operators need confidence that:
- A person record was either created or not created — not in an unknown state
- An API key was either provisioned or not provisioned
- Any failure is communicated clearly enough to act on
ERR-17 closes two gaps where that confidence was absent.
Affected Pages
| Page | Change |
|---|---|
| Dashboard → People → New | Top-level dismissible alert for network errors; field values preserved |
| Dashboard → Settings | Error feedback on API key creation failure |