PostHog error tracking + release/sourcemap pipeline for discovery-index (off the shared metagraphed Sentry project)

[JSONbored]

Part of epic #8286 (Phase 1 — Errors).

• Blocked by Provision a loopover-owned Posthog project for the hosted fleet #7875.

Current state

packages/discovery-index/src/sentry.ts (#4934) — error tracking for the hosted discovery-index service (a Node service in a Cloudflare Container at discovery.loopover.ai, so posthog-node is usable here, unlike a Workers isolate). Two things make this surface special:

1. It currently reports into the shared metagraphed Sentry project (its own header documents this) — there was no loopover-owned project to point at when it shipped. Migrating it gives it a loopover-owned home for the first time and removes a cross-project entanglement ahead of metagraphed's own Sentry sunset (Sentry decommission (repo side): gated cutover checklist metagraphed#7766).
2. It has a full release/sourcemap pipeline: src/upload-sourcemaps.ts (@sentry/cli), scripts/validate-sentry-release.mjs, scripts/validate-sourcemaps.mjs — release + sourcemap upload are part of its deploy, and the validators gate drift.

Deliverables

• Swap the capture sink to PostHog $exception via posthog-node, preserving the module's existing shape: field-name + value-pattern redaction (SECRET_FIELD/SECRET_VALUE), fingerprints, levels, the DISCOVERY_INDEX_SENTRY_TAG_KEYS tag allowlist (renamed accordingly).
• Replace the @sentry/cli release/sourcemap pipeline with the PostHog equivalent (posthog-cli sourcemap inject + upload, release tagging), and update both validator scripts to validate the PostHog artifacts instead.
• Point at the loopover-owned project (Provision a loopover-owned Posthog project for the hosted fleet #7875's key, injected as this service's secret — coordinate naming with Wire hosted control-plane + tenant containers to report to the central PostHog project (implements #4934) #7876's control-plane conventions).
• Sentry path stays wired in parallel until the decommission gate.
• Tests: capture/redaction parity with the existing sentry tests; validator scripts against a fixture build.

Boundaries

• review-enrichment's identical-shaped swap is its own sub-issue (separate deploy, separate secrets).

Resources

• https://posthog.com/docs/error-tracking/upload-source-maps and https://posthog.com/docs/error-tracking/releases
• feat(ui): add PostHog error tracking and source-map upload metagraphed#7785 (the sourcemap-pipeline mirror, UI-side there)

[linear-code]

JSO-5732

[JSONbored]

Implementation notes on a few decisions worth recording:

validate-sourcemaps.mjs is unchanged. It turned out to already be fully provider-agnostic — it only checks the on-disk build artifact shape (dist/server.js/server.js.map exist, sourceMappingURL present, sourcesContent embedded), with zero Sentry API calls or Sentry-specific logic. Nothing to swap.

New validate-posthog-release.mjs is PostHog's counterpart to validate-sentry-release.mjs, but deliberately scoped narrower than its Sentry sibling: PostHog's release model has no equivalent of Sentry's separate commits/deploys/finalize lifecycle — a release is just a version string baked into an uploaded symbol set's metadata as a byproduct of posthog-cli sourcemap upload. This script verifies the narrower, honest claim that model actually supports: at least one symbol set exists for the release (via GET /api/projects/:id/error_tracking/symbol_sets), and none of them recorded a failure_reason. Wired into upload-sourcemaps.ts's PostHog leg with the same retry/attempts/delay knobs as the Sentry validator (DISCOVERY_INDEX_POSTHOG_VALIDATE_RELEASE/_ATTEMPTS/_RETRY_DELAY_MS).

Pipeline ordering: upload-sourcemaps.ts runs Sentry's leg first (existing, unmodified), then PostHog's leg second. Both mutate the same on-disk .js/.map files via their own inject step (Sentry's debug_id comment vs PostHog's chunkId comment) — I can't fully verify these two injections coexist cleanly without a live deploy, so ordering it this way means if there's ever an unexpected interaction, the proven Sentry leg (which runs first) isn't put at risk by the newer one. Worth watching on the first real deploy.

Env vars are all wired but pending #7875. POSTHOG_API_KEY/POSTHOG_HOST/POSTHOG_ENVIRONMENT/POSTHOG_RELEASE (event capture) and POSTHOG_CLI_API_KEY/POSTHOG_CLI_PROJECT_ID/POSTHOG_CLI_HOST (sourcemap upload, a PostHog personal API key — distinct from the project token) are declared, forwarded through the Container, and fully wired end-to-end — but not yet added as real wrangler.jsonc vars/secrets, since #7875 (a real loopover-owned PostHog project provisioned through the proper control-plane secret path) isn't finished. Every PostHog code path stays a complete no-op until then, same as an unset SENTRY_DSN today.