Part of #74. Depends on #75/#77 (both landed via PR #111). Re-scoped after #111: the recordUsage.screen/feature helpers are dropped from scope — front-end feature/screen usage telemetry is handled by the host app via PostHog, not Sentry (see docs/sentry-integration.md §9.2). Sentry stays focused on bug reporting and performance.
Spec: docs/sentry-integration-plan.md Phase 5 (what remains usage-tier) + §11.4.
Deliverables
Tests
- Toggle on ⇒ usage-gated captures present; toggle off ⇒ absent (the duration metric stays diagnostic-tier)
- Sync-session transaction carries only the allowed bucketed values
Part of #74. Depends on #75/#77 (both landed via PR #111). Re-scoped after #111: the
recordUsage.screen/featurehelpers are dropped from scope — front-end feature/screen usage telemetry is handled by the host app via PostHog, not Sentry (seedocs/sentry-integration.md§9.2). Sentry stays focused on bug reporting and performance.Spec:
docs/sentry-integration-plan.mdPhase 5 (what remains usage-tier) + §11.4.Deliverables
comapeo.sync.sessiontransaction covering each sync session, with child spans for discover / handshake / replicate. Carries only bucketed peer count, bucketed bytes, and outcome — no peer identities, no raw project IDs (§11.3)metrics.syncSession(outcome, ms, peersBucket, bytesBucket)emitter (backend/lib/metrics.js) from the same lifecycle plumbing — the helper and its peers/bytes bucket functions exist but currently have no call site, socomapeo.sync.session.duration_msand the bucket counters never emitAppStatechanges, so errors can be read as "fired 3 seconds after the app was backgrounded"docs/sentry-integration.mdTests