Migrate sentry-raven -> sentry-ruby 6.7 (adds deploy release tracking)

[avitus]

Summary

• Replaces the EOL sentry-raven 3.1.2 SDK (unmaintained since 2021) with sentry-ruby / sentry-rails / sentry-sidekiq 6.7.0
• Production errors are now tagged with the deployed git SHA — the SDK reads Capistrano's REVISION file at boot, so errors correlate directly to deploys with no deploy-side changes and no new secrets
• Sidekiq worker errors (reminders, quizzes, metrics) are now captured — the raven setup never hooked Sidekiq
• Privacy strictly improves: with send_default_pii off (default), request bodies, cookies, and IPs are not sent at all (raven sent sanitized bodies)
• Migrates the one legacy call site (app/lib/bible_gateway.rb) from Raven.tags_context to Sentry.set_tags

Design spec: documentation/specs/2026-08-11-sentry-release-tracking-design.md
Implementation plan: documentation/plans/2026-08-11-sentry-release-tracking.md

Test results (run serially at HEAD c1c63eb)

Suite	Run	Passed	Failed	Pending
RSpec	1233 examples	1233	0	25
Vitest	409 tests	409	0	—
Cucumber	72 scenarios / 559 steps	72 / 559	0	—

Post-deploy verification (one-time)

1. From a production Rails console: Sentry.capture_message("release tracking test")
2. Confirm the event appears in Sentry tagged with the deployed 40-char SHA and that a release record now exists
3. Bonus check: fire one from a Sidekiq worker context too, confirming the worker-side release tag

Note: Sentry.configuration.release is nil outside production by design — on sentry-ruby 6.x, release detection only runs where sending is enabled. This will also settle whether the 90-day Sentry event silence was app health or broken raven delivery.

Follow-up candidates (out of scope here)

• BibleGateway sets tags but never captures an event (parity with old raven behavior) — consider Sentry.with_scope + capture_exception if persistent failures should be visible
• Consider pinning the sentry gems (~> 6.7) to avoid a silent future major jump

🤖 Generated with Claude Code

Summary by CodeRabbit

• Improvements
  • Upgraded error monitoring for more reliable reporting across the application and background tasks.
  • Sentry events now identify the deployed release automatically, improving troubleshooting across versions.
  • Error reporting is limited to production and configured to avoid collecting personally identifiable information.
  • Bible Gateway connection failures now include service and HTTP status details after retries.
• Documentation
  • Added guidance for monitoring verification and release tracking.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: c017dd27-6443-49c1-aad8-c63d199f8250

📥 Commits

Reviewing files that changed from the base of the PR and between c1c63eb and c559dc3.

📒 Files selected for processing (2)

• documentation/plans/2026-08-11-sentry-release-tracking.md
• spec/lib/bible_gateway_spec.rb

🚧 Files skipped from review as they are similar to previous changes (2)

• spec/lib/bible_gateway_spec.rb
• documentation/plans/2026-08-11-sentry-release-tracking.md

---

📝 Walkthrough

Walkthrough

The application replaces sentry-raven with modern Sentry integrations. Sentry initialization now uses production gating and automatic release detection. BibleGateway errors use Sentry tags. New specs and migration documents define configuration, verification, and deployment checks.

Changes

Sentry migration

Layer / File(s)	Summary
Sentry configuration and SDK migration Gemfile, config/initializers/sentry.rb, spec/initializers/sentry_spec.rb, documentation/specs/..., documentation/plans/...	The project uses sentry-ruby, sentry-rails, and sentry-sidekiq. The initializer uses Sentry.init with production-only reporting and ActiveSupport breadcrumbs. Specs and documents define PII, DSN, and release-detection behavior.
BibleGateway error tagging app/lib/bible_gateway.rb, spec/lib/bible_gateway_spec.rb, documentation/specs/..., documentation/plans/...	BibleGateway replaces guarded Raven.tags_context calls with Sentry.set_tags. Specs cover persistent HTTP 503 failures and expected tags.
Migration verification and deployment checks documentation/plans/..., documentation/specs/...	The documents define full-suite validation, post-deployment event delivery checks, deployed SHA release verification, and excluded work.

Estimated code review effort: 3 (Moderate) | ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the Sentry SDK migration and the added deploy release tracking.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/sentry-sdk-migration

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 4

🤖 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 `@documentation/plans/2026-08-11-sentry-release-tracking.md`:
- Line 9: Update the release-tracking plan’s SDK references around the Tech
Stack and related sections to use version 6.7.0, and reorder the release
detector precedence to SENTRY_RELEASE, then git SHA, then Capistrano REVISION.
Keep the plan consistent with the lockfile, initializer, and design
specification.
- Around line 118-133: Add a test covering ActiveSupport logger breadcrumbs with
sentinel password and token values, then update the Sentry.init configuration to
define config.before_breadcrumb that filters breadcrumb.data via
ActiveSupport::ParameterFilter using Rails.application.config.filter_parameters
before returning the breadcrumb. Keep the existing send_default_pii request-body
decision logic unchanged.

In `@spec/initializers/sentry_spec.rb`:
- Around line 3-8: Add isolated production release-detection examples to the
Sentry configuration spec: verify Sentry.configuration.release reads a temporary
REVISION file, and verify SENTRY_RELEASE takes precedence over it. Stub or
isolate Git SHA detection so the REVISION case exercises the Capistrano
fallback, and ensure temporary files and environment variables are restored
after each example.

In `@spec/lib/bible_gateway_spec.rb`:
- Around line 31-43: Update the persistent HTTP failure example around
gateway.lookup to assert that URI.open is called exactly three times, and verify
gateway.sleep receives backoff values 1 and 2 in order while retaining the
Sentry tag expectation.

🪄 Autofix

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 Plus

Run ID: ddb87dde-6c0c-4c4b-a8aa-86f36e8d45c6

📥 Commits

Reviewing files that changed from the base of the PR and between 48c198c and c1c63eb.

⛔ Files ignored due to path filters (1)

• Gemfile.lock is excluded by !**/*.lock

📒 Files selected for processing (7)

• Gemfile
• app/lib/bible_gateway.rb
• config/initializers/sentry.rb
• documentation/plans/2026-08-11-sentry-release-tracking.md
• documentation/specs/2026-08-11-sentry-release-tracking-design.md
• spec/initializers/sentry_spec.rb
• spec/lib/bible_gateway_spec.rb

[avitus]

CodeRabbit review — all 4 threads processed

Commit: c559dc38

✅ Fixed (2)

1. Plan doc stale SDK version + detection order (documentation/plans/...md:9)
Synced the plan to the resolved SDK version: Tech Stack now says 6.7.0 (was "latest 5.x"), Step 3's expected bundler output updated, and the Global Constraints detection order corrected to SENTRY_RELEASE → git SHA → REVISION (matching the initializer, design spec, and sentry-ruby-6.7.0/lib/sentry/release_detector.rb).

2. BibleGateway retry test precision (spec/lib/bible_gateway_spec.rb:43)
The persistent-failure test now asserts URI.open is called exactly 3 times and that backoff runs sleep(1) then sleep(2) in order, alongside the existing Sentry tag assertion. Note: ordering is asserted via pre-declared expect(...).to receive(:sleep).with(n).ordered message expectations rather than have_received(...).ordered — RSpec does not support .ordered on spies for the same message with different arguments (verified: the spy form fails with "received :sleep out of order"). Spec green: 3 examples, 0 failures.

❌ Declined with reasoning (2)

3. Add before_breadcrumb ParameterFilter for ActiveSupport breadcrumbs (documentation/plans/...md:133, Security/Minor)
Verified against the installed sources — the suggested filter would re-filter data that is already filtered twice upstream:

• Rails 7.2 puts filtered parameters into the instrumentation payload itself: actionpack-7.2.3.1/lib/action_controller/metal/instrumentation.rb:67 — params: request.filtered_parameters (and path: request.filtered_path), so Rails.application.config.filter_parameters is applied at the source before Sentry ever sees the payload.
• sentry-rails 6.7.0 additionally slices every breadcrumb payload to a per-event key whitelist (lib/sentry/rails/configuration.rb:73, applied in breadcrumb/active_support_logger.rb via data.slice(*@allowed_keys[name])); the non-controller whitelisted keys (format, method, status, runtimes, middleware names) carry no user data.
• The app emits no custom ActiveSupport::Notifications.instrument calls (grep of app/ and lib/), so there is no unfiltered custom payload path.

4. Add isolated release-detection specs (REVISION file, SENTRY_RELEASE precedence) (spec/initializers/sentry_spec.rb:8, Major)
Declined as testing SDK internals rather than our code: detection precedence is sentry-ruby's own logic with upstream test coverage (release_detector.rb). Testing it in-app is also structurally awkward on 6.x: Configuration#detect_release short-circuits outside enabled_environments (configuration.rb:820 — return unless sending_allowed?), so the suite would have to fake a production environment and re-run Sentry.init mid-suite to exercise the chain — brittle setup that would break on SDK internals changes while only re-proving the gem's own specs. Our spec deliberately asserts the app's configuration contract (DSN, env gating, PII, breadcrumbs); the end-to-end release check is the documented one-time post-deploy verification in the design spec (§ Post-deploy verification), which exercises the real production path no local test can.

🤖 Generated with Claude Code