Skip to content

chore: add data-ingestion freshness checker - #522

Open
essentialbit wants to merge 9 commits into
mainfrom
tooling/check-data-freshness-20260726
Open

chore: add data-ingestion freshness checker#522
essentialbit wants to merge 9 commits into
mainfrom
tooling/check-data-freshness-20260726

Conversation

@essentialbit

Copy link
Copy Markdown
Owner

Summary

  • New scripts/check_data_freshness.py: read-only diagnostic reporting staleness of signals/news_items/signal_outcomes/trends/rag_chunks against the actual APScheduler job cadences defined in main.py, plus an informational-only section for legitimately-sparse tables (filings/divergence_events/counterfactual_runs/calibration_scores).
  • This cycle's live-DB check found signals (199h stale), news_items (116h), and signal_outcomes (118h) all far past their scheduled cadence, while trends/rag_chunks are current — consistent with main.py's own Flask/APScheduler process not currently running continuously on this Mac (only touched via one-off script invocations from the sensor/interactive sessions). The script documents this diagnosis so future cycles don't have to re-derive it via ad hoc SQL.
  • Self-directed tooling under the established empty-eligible-backlog precedent (no debated feature_backlog item this cycle scored ≥0.55) — same class as check_sensor_health.py/feat: scripts/check_sensor_health.py -- detect silent hourly-sensor outages #496, eligible_backlog.py/feat: eligible-backlog cross-reference script (closes #271) #272, etc. Does not attempt to start main.py itself; that's a systemic operational decision flagged for the user, not sensor-actionable.

Test plan

  • python3 -c "import ast; ast.parse(...)" on the new script
  • PYTHONPATH=. venv/bin/python3 scripts/check_data_freshness.py run against the live DB, output verified correct (3 stale, 2 ok, 4 informational)
  • PYTHONPATH=. venv/bin/python3 -c "from main import app" still imports cleanly (225 routes, no collision)
  • CI green

🤖 Generated with Claude Code

Saifodius and others added 9 commits July 26, 2026 08:22
signals/news_items/signal_outcomes are all 5-8 days stale on the live DB
while trends/rag_chunks are current -- confirms main.py's own APScheduler
process isn't currently running (scheduled jobs never fire from one-off
script invocations, which is how the sensor/interactive sessions actually
touch this DB). scripts/check_data_freshness.py gives future cycles a
one-shot read of which ingestion tables are stale vs their real job cadence,
instead of re-deriving this by hand via ad hoc SQL each time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant