figure-out-why-the-browser-data-is-not-being-collected-by-sentry-485 #492

Merged

johnsturgeon merged 2 commits from figure-out-why-the-browser-data-is-not-being-collected-by-sentry-485 into main

2026-09-07 12:38:28 +02:00

johnsturgeon commented

2026-09-07 12:14:56 +02:00

Owner

No description provided.

johnsturgeon added 2 commits

2026-09-07 12:14:56 +02:00

Enabling browser trace a488349cd7

I had included the wrong source and also now adding the integration and increased the sample from 0 so that it would actually capture samples

Resolves #485

fixed comment

Claude Code Review / claude-review (pull_request) Successful in 1m23s

Details

Python FastAPI Jinja Linting / build (pull_request) Successful in 27s

Details

Tests / pytest (pull_request) Successful in 13s

Details

Release on merge / release (pull_request) Successful in 0s

Details

a31482c992

forgejo-actions commented

2026-09-07 12:16:20 +02:00

Summary

This PR switches the Sentry browser SDK to the tracing bundle, adds the BrowserTracing integration, and bumps tracesSampleRate from 0.0 to 1.0 in base.j2, while adding the same Sentry loader to two previously un-instrumented standalone templates (allpicksbase.j2, setting_up.j2). The wiring is correct for Sentry v7 and should get browser data flowing, but the 100% trace sample rate interacts badly with the auto-refreshing pages, and the instrumentation still misses the admin (v2) pages.

Worth fixing

tracesSampleRate: 1.0 on auto-refreshing pages will flood Sentry's performance quota. allpicksbase.j2:79 reloads the page every 30s (setInterval('autoRefresh()', 30000)) and setting_up.j2:7 uses <meta http-equiv="refresh" content="60">. With BrowserTracing at a 1.0 sample rate, every reload emits a full pageload transaction, so an open allpicks tab generates ~2 transactions/minute/viewer indefinitely, and the setup page 1/minute. On a metered Sentry plan that's a lot of continuous spend for little signal. Consider a low sample rate (e.g. 0.1) or overriding it downward on the auto-refreshing templates.
Admin (v2) pages still collect no browser data. All v2/admin* templates extend app/templates/v2/base_v2.j2 (see the extends matches), which has no Sentry loader (app/templates/v2/base_v2.j2:18 <head> has none). If the goal is "figure out why browser data is not being collected," the admin surface remains uninstrumented. Either add the loader there too or note the omission is intentional.
The Sentry init block is now duplicated verbatim across three templates (base.j2:15-31, allpicksbase.j2:23-39, setting_up.j2:18-34). A single {% include "_sentry.j2" %} partial would keep the DSN, sample rate, and SDK version from drifting between copies — which matters directly given the sample-rate concern above (you'd otherwise have to fix it in three places).

Nits

replaysSessionSampleRate: 0.0 is a no-op here — no Replay integration is loaded and the tracing bundle doesn't include Replay, so the setting has nothing to act on. Harmless, but misleading; drop it or add the integration if replays are actually wanted.
data-lazy="no" (all three templates) is an attribute for Sentry's loader script; with the full CDN bundle it has no effect. Leftover from the loader approach.
dsn, environment, and release are interpolated straight into a JS string literal ({{ config.SENTRY_DSN }}, etc.). These are trusted config values so the risk is negligible, but a stray " or </script> in any of them would break the page; not worth changing unless you want defensiveness.

The DSN being exposed client-side is expected and not a security issue — Sentry DSNs are designed to be public.

## Summary This PR switches the Sentry browser SDK to the tracing bundle, adds the `BrowserTracing` integration, and bumps `tracesSampleRate` from `0.0` to `1.0` in `base.j2`, while adding the same Sentry loader to two previously un-instrumented standalone templates (`allpicksbase.j2`, `setting_up.j2`). The wiring is correct for Sentry v7 and should get browser data flowing, but the 100% trace sample rate interacts badly with the auto-refreshing pages, and the instrumentation still misses the admin (`v2`) pages. ## Worth fixing - **`tracesSampleRate: 1.0` on auto-refreshing pages will flood Sentry's performance quota.** `allpicksbase.j2:79` reloads the page every 30s (`setInterval('autoRefresh()', 30000)`) and `setting_up.j2:7` uses `<meta http-equiv="refresh" content="60">`. With `BrowserTracing` at a 1.0 sample rate, every reload emits a full pageload transaction, so an open allpicks tab generates ~2 transactions/minute/viewer indefinitely, and the setup page 1/minute. On a metered Sentry plan that's a lot of continuous spend for little signal. Consider a low sample rate (e.g. `0.1`) or overriding it downward on the auto-refreshing templates. - **Admin (`v2`) pages still collect no browser data.** All `v2/admin*` templates extend `app/templates/v2/base_v2.j2` (see the `extends` matches), which has no Sentry loader (`app/templates/v2/base_v2.j2:18` `<head>` has none). If the goal is "figure out why browser data is not being collected," the admin surface remains uninstrumented. Either add the loader there too or note the omission is intentional. - **The Sentry init block is now duplicated verbatim across three templates** (`base.j2:15-31`, `allpicksbase.j2:23-39`, `setting_up.j2:18-34`). A single `{% include "_sentry.j2" %}` partial would keep the DSN, sample rate, and SDK version from drifting between copies — which matters directly given the sample-rate concern above (you'd otherwise have to fix it in three places). ## Nits - `replaysSessionSampleRate: 0.0` is a no-op here — no `Replay` integration is loaded and the tracing bundle doesn't include Replay, so the setting has nothing to act on. Harmless, but misleading; drop it or add the integration if replays are actually wanted. - `data-lazy="no"` (all three templates) is an attribute for Sentry's *loader* script; with the full CDN bundle it has no effect. Leftover from the loader approach. - `dsn`, `environment`, and `release` are interpolated straight into a JS string literal (`{{ config.SENTRY_DSN }}`, etc.). These are trusted config values so the risk is negligible, but a stray `"` or `</script>` in any of them would break the page; not worth changing unless you want defensiveness. The DSN being exposed client-side is expected and not a security issue — Sentry DSNs are designed to be public.

johnsturgeon merged commit e74c6b61f2 into main

2026-09-07 12:38:28 +02:00

johnsturgeon deleted branch figure-out-why-the-browser-data-is-not-being-collected-by-sentry-485

2026-09-07 12:38:29 +02:00

johnsturgeon referenced this pull request from a commit

2026-09-07 12:38:29 +02:00

Merge pull request 'figure-out-why-the-browser-data-is-not-being-collected-by-sentry-485' (#492) from figure-out-why-the-browser-data-is-not-being-collected-by-sentry-485 into main