Problem
The pipeline is multi-step (Telegram fetch → extraction → embeddings → topics → scheduling → writing → publishing). When something fails or stalls, users rely on console logs, which makes it hard to:
- see what ran last
- understand what changed
- debug failures quickly
Goal
Introduce lightweight observability so users and contributors can diagnose runs and failures quickly.
Proposed approach
- Add a
pipeline_runs table (or similar) that stores:
- run id
- start/end timestamps
- step-level counts
- failure summaries
- Emit structured logs (JSON optional)
- Add improved error surfacing:
- include root exception messages (avoid swallowing)
- include target URLs, status codes, and retry state
Acceptance criteria
- Each analyze/schedule/write/publish run is recorded
- CLI prints a concise summary + points to run id
- Failures include actionable error messages
Tasks
Problem
The pipeline is multi-step (Telegram fetch → extraction → embeddings → topics → scheduling → writing → publishing). When something fails or stalls, users rely on console logs, which makes it hard to:
Goal
Introduce lightweight observability so users and contributors can diagnose runs and failures quickly.
Proposed approach
pipeline_runstable (or similar) that stores:Acceptance criteria
Tasks