getsentry / getsentry/sentry-javascript

Loader stub silently drops calls outside queued method list, which results in either silent no-ops

Open Beginner friendly
#21,806 2 comments 0 reactions 0 assignees View on GitHub
Feature Package-Meta: Loader
Dominant language
TypeScript
Stars
8.7k
Forks
1.8k
Avg merge
1d 17h
Merged PRs (30d)
515

Description

### Problem Statement

## Problem

The CDN loader stub only queues a fixed set of SDK methods pre-load (`init`, `addBreadcrumb`, `captureMessage`, `captureException`, `captureEvent`, `configureScope`, `withScope`, `showReportDialog`). Any SDK call outside this list — such as `addIntegration` — is silently absent on the `window.Sentry` proxy before the full bundle loads, causing either silent no-ops or runtime crashes depending on timing.

The correct workaround is wrapping such calls in `Sentry.onLoad(...)`, but the loader provides no mechanism to enforce this, making it easy to write code that works in development (where the bundle may already be loaded) but crashes in production.

## Current Behavior

- Unrecognized calls on the pre-load proxy are `undefined` — calling them throws or silently does nothing
- `addIntegration` is a notable gap: it is a common post-init call pattern that the loader stub does not queue

## Gap

- No TypeScript or runtime guardrail prevents calling unqueued methods before `onLoad`
- The failure mode is timing-dependent and hard to reproduce locally

### Solution Brainstorm

## Options

1. **Extend the queued method list** — add `addIntegration` (and other commonly used post-init methods) to the pre-load queue so they are replayed after the bundle loads, consistent with how `init` is handled
2. **Catch-all no-op proxy** — intercept any unrecognized property access pre-load and return a no-op function; prevents crashes but silently swallows calls
3. **Catch-all replay proxy** — queue all unrecognized calls (not just the fixed list) and attempt replay post-load; broader coverage but requires more careful handling of methods with return values

Option 1 is the lowest-risk and most targeted fix. Option 3 is the most ergonomic for callers but adds complexity to the replay logic.

### Additional Context

## References

- Loader stub source: `packages/browser-integration-tests/fixtures/loader.js`
- `addIntegration` implementation: `packages/core/src/integration.ts`

### Priority

React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding `+1` or `me too`, to help us triage it.

Contributor guide

Open the contributing guide

Research direction

Start by reading packages/browser-integration-tests/fixtures/loader.js to trace the pre-load method queue, then compare its entries with the addIntegration implementation in packages/core/src/integration.ts. Confirm how queued calls are replayed after loading and verify that the chosen guardrail handles addIntegration without changing existing queued methods.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, typescript
Domain
frontend
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.