Show underlying GitLab connection failures in the UI and logs
Summary
GitLab connection failures now show the underlying TLS, DNS, or socket cause in the UI and write the same diagnostic to the local main-process log. This makes failures such as fetch failed actionable when curl can reach a self-hosted instance but Dyad cannot.
- Include nested cause messages and error codes, including individual attempts inside aggregate connection failures. Bound traversal and diagnostic length, flatten log lines, and redact the configured access token before truncation.
- Keep diagnostics local and retain the existing GitLab error classification and telemetry exclusion. Log only the projected message, without raw errors, stacks, request headers, or bodies; internal hostnames may remain useful for troubleshooting.
- Preserve cancellation behavior and timeout guidance. The credentials form already renders IPC error messages, so it displays the added cause through the existing error presentation.
[!NOTE]
Low Risk
Localized error-message and logging improvements with token redaction and existing telemetry filtering; no auth or API contract changes.
Overview
GitLab connect failures no longer stop at generic fetch failed text. The main-process client now walks nested cause chains (including AggregateError attempts), builds a bounded one-line diagnostic with TLS/DNS/socket codes, redacts the PAT before truncation, and logs that same string locally while still throwing GitLabTransportError.
Timeouts, user cancellation, and HTTP error mapping are unchanged; the credentials form picks up the richer IPC message automatically, with a new UI test for TLS-style errors and retry. Internal docs note that Node main-process fetch differs from Chromium/net.fetch when debugging self-hosted trust or proxy issues.
Reviewed by Cursor Bugbot for commit 903089bb73ce9aaf0fa80aea9e283f8aea9aa85a. Bugbot is set up for automated code reviews on this repo. Configure here.