[NX-103] Handle unreachable targets gracefully in API and UI #9

New Issue

nessi · 2026-02-13T13:13:07Z

nessi commented

2026-02-13 13:13:07 +00:00

Goal

Avoid 500 errors for expected runtime issues (target down, network refused).

Scope

Return meaningful API errors for connectivity failures.
Show clean state in UI (e.g., unreachable/offline) instead of raw errors.

Acceptance Criteria

No generic 500 for target connection failures.
User-facing message is clear and actionable.

## Goal Avoid 500 errors for expected runtime issues (target down, network refused). ## Scope - Return meaningful API errors for connectivity failures. - Show clean state in UI (e.g., unreachable/offline) instead of raw errors. ## Acceptance Criteria - No generic 500 for target connection failures. - User-facing message is clear and actionable.

nessi added this to the v1.0 - Stability, Reliability & Security (P0) milestone 2026-02-13 13:13:07 +00:00

nessi added the P0 label 2026-02-13 13:13:07 +00:00

nessi added reference development

2026-02-14 14:55:02 +00:00

nessi commented

2026-02-14 15:02:41 +00:00

Implemented for NX-103.

Goal Achieved

Expected runtime connectivity issues (target down / refused network) no longer surface as noisy generic UI failures.

Scope Delivered

Backend already returns structured connectivity errors for runtime target failures:
- 503 with code: target_unreachable
- includes actionable details (target_id, host, port, error)
Frontend Target Detail handling was updated to treat connectivity failures as a clean runtime state:
- Added explicit unreachable/offline detection (target_unreachable / 503)
- Replaced raw error rendering with a dedicated Target Offline card
- Shows clear action guidance and technical context (host, port, optional request_id)
Data loading flow now remains stable:
- metrics/meta continue loading where possible
- live connectivity-dependent sections degrade gracefully when target is offline

Acceptance Criteria

✅ No generic 500-style user-facing failure for expected target connection outages.
✅ User-facing message is clear and actionable.
✅ Runtime connectivity problems are represented as a clean UI state (offline/unreachable), not raw exception text.

Notes

This is a UX/error-handling improvement for expected runtime conditions; no DB migration required.

Implemented for **NX-103**. ## Goal Achieved Expected runtime connectivity issues (target down / refused network) no longer surface as noisy generic UI failures. ## Scope Delivered - Backend already returns structured connectivity errors for runtime target failures: - `503` with `code: target_unreachable` - includes actionable `details` (`target_id`, `host`, `port`, `error`) - Frontend Target Detail handling was updated to treat connectivity failures as a clean runtime state: - Added explicit unreachable/offline detection (`target_unreachable` / `503`) - Replaced raw error rendering with a dedicated **Target Offline** card - Shows clear action guidance and technical context (`host`, `port`, optional `request_id`) - Data loading flow now remains stable: - metrics/meta continue loading where possible - live connectivity-dependent sections degrade gracefully when target is offline ## Acceptance Criteria - ✅ No generic 500-style user-facing failure for expected target connection outages. - ✅ User-facing message is clear and actionable. - ✅ Runtime connectivity problems are represented as a clean UI state (offline/unreachable), not raw exception text. ## Notes - This is a UX/error-handling improvement for expected runtime conditions; no DB migration required.

nessi closed this issue

2026-02-14 15:02:42 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: nessi/NexaPG#9