feat(selfhost): trace review pipeline in Sentry

[oktofeesh1]

Summary

• bridge Sentry into the self-host custom OpenTelemetry provider so sampled review spans reach Sentry without competing tracer setup
• add hashed installation tags and review-stage spans for readiness, AI review, gate evaluation, publishing, and maintenance
• document Sentry trace sampling in the self-host operations docs

What changed

• added the @sentry/opentelemetry bridge path with Sentry propagator/context manager and optional sampler/span processor
• changed SENTRY_TRACES_SAMPLE_RATE handling so unset/blank fully disables Sentry trace export, while positive values enable sampled Sentry spans
• kept OTLP and Sentry sampling independent in combined exporter setups by recording spans at the provider and filtering OTLP/Sentry processors with their respective samplers
• preserved processor-specific parent sampling context so parent-based OTLP sampling cannot inherit Sentry/provider sampling decisions
• replaced raw installation ID Sentry tags/contexts with stable installation_id_hash
• removed the weak fallback installation-id digest so Sentry scrubbing drops raw ids until the SHA-256 hasher is loaded
• added focused self-host and queue regression tests for tracing, sanitization, sampler isolation, and cache fallback behavior

Why

Self-host operators could see trace ids on events, but Sentry was not integrated with the custom OTEL provider and issue #1001's per-installation hashing was missing. This makes review latency/failure stages searchable in Sentry while keeping tenant identifiers privacy-preserving.

Closes #1001.

Validation

• npm run test:ci
• npm audit --audit-level=moderate
• patch coverage spot-check: 149/149 changed executable lines and 147/147 changed branches covered

Notes

• npm run test:ci completes with existing UI Fast Refresh warnings during ui:lint; there are no lint errors.

[gittensory-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-01 07:00:01 UTC}

16 files · 1 AI reviewer · no blockers · readiness 73/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review

Review summary
This change routes self-host review tracing through OpenTelemetry and lets Sentry consume those spans through its OTEL bridge while replacing raw installation identifiers with stable hashes in Sentry contexts/tags. The independent sampler path in src/selfhost/otel.ts is coherent: when OTLP and Sentry are both active, the provider records spans and each processor applies its own sampler, so Sentry sampling is not ignored. I do not see a reachable correctness break in the provided diff; the remaining concerns are observability precision and avoidable overhead.

Nits — 7 non-blocking

• nit: src/server.ts:293 builds the Sentry OpenTelemetry bridge whenever Sentry is enabled, even when Sentry tracing is blank/unset and OTLP export is disabled, which unnecessarily imports @​sentry/opentelemetry for error-only deployments.
• nit: src/selfhost/review-tracing.ts:52 computes async review trace attributes, including the installation hash, before withOtelSpan can no-op, so every review path pays that cost even when tracing is disabled.
• nit: src/queue/processors.ts:5161 labels the whole AI-review cache block with agent: "dual-ai", so cache hits will be reported as agent spans even though no model call ran.
• nit: src/selfhost/sentry.ts:420 only tags decision_outcome, while the new tracing input uses decisionOutcome, so any future caller passing the camelCase field into captureReviewFailure would silently miss the tag.
• Gate the src/server.ts:293 bridge construction on either positive SENTRY_TRACES_SAMPLE_RATE or openTelemetryTraceExportEnabled(process.env), or make buildSentryOpenTelemetryBridge return before importing @​sentry/opentelemetry when no bridge can be used.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#1001
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (size label size:XL; 1 linked issue).
Validation posture	❌ 5/25	Preflight is holding this PR; address the blocker before review.
Contributor workload	✅ 10/10	Author activity: 72 registered-repo PR(s), 62 merged, 6 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	oktofeesh1; Gittensor profile; 72 PR(s), 6 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: oktofeesh1
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 72 PR(s), 6 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Fix the blocker.
• Triage stale or unlinked PRs.
• Refresh registry data or choose a registered active repo.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review