staging: /api/beats returns 500, beat lookups 404 — seed data incomplete

[arc0btc]

Summary

The staging preview at agent-news-staging.hosting-962.workers.dev is missing all beat records, even though signal seed data references them. This blocks any smoke test that needs to POST /api/signals, since beat-lookup is the first gate.

Reproduction

$ curl -sS https://agent-news-staging.hosting-962.workers.dev/api/beats
{"error":"Internal server error"}                              # HTTP 500

$ for slug in quantum bitcoin-macro aibtc-network agent-economy agent-skills; do
    curl -sS "https://agent-news-staging.hosting-962.workers.dev/api/beats/$slug"
  done
{"error":"Beat \"quantum\" not found"}
{"error":"Beat \"bitcoin-macro\" not found"}
{"error":"Beat \"aibtc-network\" not found"}
{"error":"Beat \"agent-economy\" not found"}
{"error":"Beat \"agent-skills\" not found"}

The first two slugs are production-active; the last two have signals in GET /api/signals on the same preview, so the seed clearly intended to populate them.

Impact

• GET /api/beats 500 → blocks beat discovery (and anything that depends on listBeats).
• All POST /api/signals returns 404 at the beat-lookup step before identity, payment, retirement, or any other check can fire.
• The smoke test in docs/x402-signal-payment-smoke-test.md cannot exercise steps 2, 3, 4, 5, 6, 7, 8, 10b on this preview.

Likely cause

Whatever fixture/migration seeds beats either failed silently or was skipped on this preview deploy. Worth checking the preview build logs and the seed step ordering relative to schema migration v30 from PR #802.

Filed in lieu of blocking PR #802

The PR itself looks good in everything we could test (8/11 smoke-test steps pass, including the P1 edge-cache fix from 060e7e8). Filing this separately so PR #802 doesn't get held up on a preview-environment data issue.

[whoabuddy]

PR #802 merged at `c92d1ba` based on the 8/11 best-effort smoke test you ran. The 3 blocked steps were all gated on the missing beat-seed data, not on PR #802 itself, and live traffic plus arc's automated dispatch will exercise those paths post-merge.

This issue tracks the staging-preview seed problem on its own. Worth checking before the next paid-endpoint smoke test so we don't lose another 3 of 11 steps.

[arc0btc]

Root Cause Analysis

Confirmed the staging DO is still broken as of 2026-05-04T23:00Z. Here's exactly what's happening:

Two separate failures

Failure 1: GET /api/beats → 500
The beat_editors table doesn't exist in the staging DO's SQLite. The /beats list handler queries beat_editors unconditionally (even when beats is empty), which throws no such table: beat_editors, caught at the Worker level as a generic 500.

Failure 2: GET /api/beats/:slug → 404 for all slugs
The beats table exists but is empty — no rows at all. This explains why all 13 expected beats (retired + active) return 404.

Why the two behaviors differ

The /beats/:slug handler exits early on empty results before reaching the beat_editors query:

if (rows.length === 0) return c.json({ ok: false, error: `Beat "" not found` }, 404);
// beat_editors query is only reached AFTER this — never fires for missing beats

The /beats list handler always runs all three queries regardless of whether beats is empty, so the beat_editors throw surfaces.

Why beat_editors is missing

beat_claims and beat_editors are not in SCHEMA_SQL — they're only created by migrations v8 and v17. If the staging DO is in a state where migration_version was already written >= 17 (e.g. from a prior deployment) but the actual SQL tables weren't created (storage partially reset, or a prior migration failed silently), those tables never get created again.

Proposed fix

Part 1 (structural fix): Add beat_claims and beat_editors to SCHEMA_SQL as CREATE TABLE IF NOT EXISTS. Since SCHEMA_SQL runs on every DO cold start (line 894 of news-do.ts), this would heal any existing broken DO on next restart — no migration version bump needed.

Part 2 (seed fix): Extend POST /api/internal/seed (the /test-seed DO route) to also accept a beats array and add the 3 canonical beats to fixtures/seed-staging.json. Currently the seed endpoint handles signals, signal_tags, classifieds, etc. but not beats. The preview.yml warm-up comment says "triggers schema migrations + beat seeding" but no beat seeding actually happens — migrations insert beats only if migration_version is below the relevant threshold.

Happy to open a PR with these two changes if useful.