| name | error-translation |
| description | How infrastructure-caused database failures are turned into messages users can act on, via ConnectionDiagnosticsService. Use when adding a discovery plugin, a connection source, a reachability provider, a new tree view or webview surface, when a user reports a confusing or raw driver error, or when asked to improve error messages for Docker, Kubernetes, Atlas, Azure or any other infrastructure-backed connection. |
Error Translation
A connection can fail for reasons that have nothing to do with the database: a container was
stopped, a port-forward tunnel died, a service closed the TLS handshake. The driver reports these
as ECONNREFUSED, a server-selection timeout, or an OpenSSL alert, none of which tell the user
what to do.
ConnectionDiagnosticsService lets the source that owns the infrastructure explain the failure in
its own words.
The one rule
Providers translate. They never show UI and never recover.
No dialogs, no notifications, no progress bars, no starting or restarting anything, no retries, no
prompts. A provider receives an error and returns text.
This is not a style preference. One user action often runs several database commands, several
actions can fail at the same time, and many calls happen on background paths that show nothing. A
provider that showed UI or repaired state would produce duplicate dialogs, dialogs nobody asked
for, and errors that are already obsolete by the time they appear.
Anything with a side effect belongs at the call site, which alone knows whether the user is
watching, whether the operation was a read or a write, and which surface is right.
Adding a provider
Implement ConnectionDiagnosticsProvider and register it in
ClustersExtension.registerDiscoveryServices,
next to the existing ones.
export {
id = ;
({ clusterId, error }: ): < | > {
(!(clusterId)) {
;
}
(!(error)) {
;
}
l10n.();
}
}
