getsentry / getsentry/sentry-javascript
Loader stub silently drops calls outside queued method list, which results in either silent no-ops
- Lenguaje dominante
- TypeScript
- Estrellas
- 8.7k
- Forks
- 1.8k
- Merge medio
- 1 d 17 h
- PR fusionados (30 d)
- 515
Descripción
### 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.
Guía de contribución
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- javascript, typescript
- Área
- frontend
- Tipo de issue
- Error
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Estado de actividad
- Tranquilo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 68/100