Observability & Error Tracking

The Observability panel no longer surfaces internal stack traces. Instead, it exposes a concise error summary that includes error code, context, and a direct link to the issue.

Error endpoint

When an unexpected error occurs, Hypertask logs a structured entry with minimal details:

• Code: The internal error code (e.g., 503).
• Message: A user-friendly explanation.
• Context: A JSON snippet highlighting the route, user, and request parameters.
• Link: A live link to the appropriate issue tracker.

You can see recent errors on the dashboard or fetch them programmatically via /api/observability/errors.

Real-time monitoring

A websocket connection to /api/observability/stream pushes new errors to connected clients in real time. This is useful for debugging ad-hoc issues and for dashboards that need to stay in sync.

Auto-filing errors

Errors with codes matching known patterns are automatically filed in the issue queue. The system tries to:

1. Identify the affected route or controller.
2. Extract common error scenarios (401/403/404 false positives).
3. Prioritize the entry by severity and recurrence.

Fleet status heartbeat

The fleet status heartbeat now persists on the Agents dashboard even when processes exit mid-scan. The agent-runtime collector uses a retry pattern to handle cold-start ENOENT conditions, keeping the fleet status view available continuously.

What changed

• Collector retries on /proc ENOENT race conditions, so the fleet status refreshes on schedule regardless of process churn.
• The Agents dashboard rights panel shows a stable heartbeat line when collectors are scanning; the line no longer drops unexpectedly.
• CLI task assign attaches the requested agent after the prior mutation succeeds and reloads correctly.
• The fleet ledger closes orphaned rows after worker restarts, so launches killed by a systemd long go clean.

Updated references

• Integration validation per HTPR-6253 confirms 20 non-failed scans during 800 process exits; every scan returned usable data and the combined fleet view stayed visible.
• CLI task assignment clarity per HTPR-6185, 6187: assign works without a lease claim and includes an optional claim step.
• Fleet ledger cleanup per HTPR-6310 closes orphaned rows after worker restarts, so launches killed by a systemd long go clean.

---

Tip

If you encounter persistent errors in production, open the error link in your issue tracker and attach relevant context from the dashboard that you collected at the time of the error.