Files
music_library/backlog/completed/ml-161 - pi-access-to-production-errors.md
T
Claudio Ortolina 365195ff75 Backlog cleanup
2026-05-07 10:01:47 +01:00

2.5 KiB

id, title, status, assignee, created_date, updated_date, labels, dependencies, references, priority, ordinal
id title status assignee created_date updated_date labels dependencies references priority ordinal
ML-161 pi access to production errors Done
2026-05-04 08:06 2026-05-04 13:18
pi
api
ML-162
ML-163
ML-164
backlog://document/doc-7
medium 9000

Description

Errors in production are captured via the error_tracker Elixir dependency and accessed via a dedicated dashboard at /dev/errors. There is no built-in tooling or endpoint to pull production errors programmatically in a pi session. This task covers the investigation and implementation of the best approach to expose production error data to pi, broken into three subtasks:

  1. Expose production errors via a programmatic API (behind auth) — Add a JSON API endpoint under /api/v1/errors that lists errors and shows individual error details from the error_tracker tables.
  2. Create pi tools to pull errors — Implement fetch_production_errors (list with filtering/pagination) and fetch_production_error (single error detail) as pi tools.
  3. Create a pi extension to browse errors — Build an interactive TUI browsing experience via a pi extension that uses the tools from subtask 2.

Error data attributes

These are the attributes that subtask implementations must treat as the canonical data model:

Error (from error_tracker_errors table):

  • id — UUID, unique error identifier
  • kind — string, e.g. "error", "throw", "exit"
  • reason — string, the error message/reason
  • source_line — string, e.g. "lib/foo.ex:42"
  • source_function — string, e.g. "MusicLibrary.Foo.bar/2"
  • status — atom: :resolved | :unresolved
  • fingerprint — hex string, deterministic hash of (kind, source_line, source_function)
  • last_occurrence_at — UTC datetime (microsecond precision)
  • muted — boolean
  • inserted_at / updated_at — UTC datetime

Occurrence (from error_tracker_occurrences table):

  • id — UUID
  • reason — string, error reason at time of occurrence
  • context — map, includes live_view.view, request.path, etc.
  • breadcrumbs — array of strings
  • stacktrace — embedded struct with lines array (each having: application, module, function, arity, file, line)
  • error_id — FK to error
  • inserted_at — UTC datetime

Aggregated/per-error metadata (computed, not stored):

  • occurrence_count — total occurrences for this error
  • first_occurrence_at — earliest occurrence timestamp