docs(desktop): correct Bug F diagnosis — renderer SDK was not broken#645
docs(desktop): correct Bug F diagnosis — renderer SDK was not broken#645jeevanpillay merged 2 commits intomainfrom
Conversation
Follow-up experiment on @sentry/electron 7.13.0 with the renderer SDK restored shows Sentry.getClient() returns a fully constructed client and the v10 carrier exposes it at __SENTRY__[ver].defaultCurrentScope._client (not the v8/v9 .client / .defaultClient paths I was inspecting during the dry-run). The "Sentry.init silently fails" diagnosis was wrong; the "zero events" outcome on rc.1/rc.2/rc.3 was Sentry org quota exhaustion, not a broken SDK. PR #643's main-side bridge still stands as the chosen architecture — smaller bundle, single SDK init, insulated from carrier shape changes — but as an architectural choice rather than an SDK workaround. Updates the dry-run report with a §Correction and a TL;DR callout, amends the codex-gap doc's G-12 row, and rewrites the misleading comment in apps/desktop/src/renderer/src/main.ts. No upstream issue filed — the SDK works. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughReplaces direct Sentry main SDK usage with a dedicated ChangesSentry renderer→main routing
Sequence DiagramsequenceDiagram
participant Renderer as Renderer (web)
participant IPC as IPC
participant Main as Main process
participant Obs as Observability (`sentry-electron-main`)
Renderer->>IPC: send error payload (message, stack, metadata)
IPC->>Main: forward renderer error
Main->>Obs: captureException(Error, { tags, extra })
Obs->>Obs: enrich & send to Sentry backend
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Review notes (concise, actionable)
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/desktop/src/renderer/src/main.ts`:
- Around line 21-25: Update the inline guidance in main.ts to avoid recommending
direct third-party imports: replace the reference to `@sentry/electron/renderer`
and `Sentry.init` with the repo's vendor abstraction (e.g., `@vendor/sentry` or
`@vendor/*` re-exports). Keep the same behavioral note about renderer-side
breadcrumbs/replay but instruct developers to import the renderer SDK via the
vendor abstraction (e.g., "add `@vendor/sentry` + `Sentry.init`") rather than
naming `@sentry/electron/renderer` directly so the comment aligns with the
vendor-abstraction policy.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 127df7fa-fb94-475d-a0f6-4524a2847032
⛔ Files ignored due to path filters (2)
thoughts/shared/2026-05-06-desktop-rc1-ad-hoc-dry-run-report.mdis excluded by!thoughts/**thoughts/shared/research/2026-04-23-codex-vs-lightfast-desktop-production-gap.mdis excluded by!thoughts/**
📒 Files selected for processing (1)
apps/desktop/src/renderer/src/main.ts
CodeRabbit flagged the renderer comment recommending `@sentry/electron/renderer` as a direct third-party SDK reference, which violates repo policy. Same policy violation in apps/desktop/src/main/index.ts where PR #643 added a direct `import * as Sentry from "@sentry/electron/main"` instead of routing through the existing `@vendor/observability/sentry-electron-main` re-export (which already exposes captureException). - Switch main/index.ts to import { captureException } from the vendor wrap. - Update the renderer comment to point at a hypothetical `@vendor/observability/sentry-electron-renderer` re-export rather than the underlying `@sentry/electron/renderer` SDK. - Mirror the same guidance in the dry-run report's §Correction follow-ups. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
Follow-up experiment on `@sentry/electron@7.13.0` (latest) with the renderer SDK restored shows `Sentry.getClient()` returns a fully constructed client and the v10 carrier exposes it at `SENTRY[ver].defaultCurrentScope._client` (not the v8/v9 `.client` / `.defaultClient` paths I was inspecting during the dry-run). The "Sentry.init silently fails to register a client" diagnosis from PR #643 / the dry-run report was wrong.
What actually caused "zero events ingested" on rc.1/rc.2/rc.3 was Sentry org quota exhaustion (flagged by you near the end of the dry-run) — not a broken SDK.
PR #643's main-side bridge still stands as the chosen architecture (smaller bundle, single SDK init, insulated from carrier shape changes) — but as an architectural choice, not as an SDK workaround. No upstream issue filed.
What this PR changes
Test plan
Follow-ups (separate PRs, not blocking)
🤖 Generated with Claude Code
Summary by CodeRabbit
Note: No user-facing functionality or public APIs were changed.