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

Bắt đầu bằng cách đọc packages/browser-integration-tests/fixtures/loader.js để theo dõi hàng đợi phương thức trước khi tải, sau đó so sánh các mục trong đó với phần triển khai addIntegration trong packages/core/src/integration.ts. Xác nhận cách các lệnh gọi đã được xếp hàng được phát lại sau khi tải, đồng thời kiểm tra rằng cơ chế bảo vệ đã chọn xử lý addIntegration mà không thay đổi các phương thức hiện có trong hàng đợi.

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.}