Conditional SDK Module Loading Based on Sample Rates

[smeubank]

Problem Statement

Currently, the Sentry SDK loads all configured modules (error tracking, performance monitoring, session replay, etc.) regardless of their sample rates. This means users who will never generate certain types of events due to sampling still have to download the associated code, increasing bundle size unnecessarily.

For high-traffic applications where sampling rates are very low (e.g., 1% for errors, 0.01% for replays), this creates unnecessary overhead for users who will not have these events sent to Sentry.

Current Behavior

• All SDK modules are loaded upfront
• Bundle size impact affects all users regardless of whether they'll send events
• Sample rates only determine if events are sent, not if code is loaded
  • this is the currently the intent of those sample rate configs, so i wouldn't interpret that as negative
• Sampling decisions can be made dynamically during the session based on event attributes

Desired Outcome

A stripped down "SDK" that:

1. Loads only a minimal core module initially
2. Determines if a user/session falls within "some" sampling rates
3. Dynamically imports additional modules (tracing, replay, etc.) only when needed
4. Reduces bundle size impact for users outside sampling thresholds

Proposed Solution

Architecture Changes

1. Create a lightweight core module that:

   • Handles initialization and sampling decisions
   • Contains minimal error tracking capabilities
   • Manages dynamic imports of additional features

2. Split current functionality into separate loadable chunks:

   • Performance monitoring
   • Session replay
   • User feedback
   • etc.

3. Implement dynamic loading logic

Potential Tradeoffs and Limitations

1. Loss of Dynamic/Functional Sampling Capabilities:

   • Sampling Context Data
   • Current SDK allows sampling decisions based on functional context

2. Timing Considerations:

   • Initial sampling decision must be made before knowing full context

3. Implementation Complexity:

   • Need to carefully manage module loading states
   • Must handle race conditions between dynamic imports and event generation
   • Additional complexity in managing module dependencies (should be handled already since tree shaking requires that the bundles can be stripped down already)

Discussion Points

• would there be a preload sample rate config, additionally?

[karol-f]

We have a real-world use case that aligns with this proposal. Currently, we've implemented a custom solution to achieve dynamic loading of Sentry modules based on sampling rates. Here's how we handle it:

We have 3 distinct sampling tiers:

• 10% of users get basic Sentry error logging
• 1% of users get error logging + tracing integration
• 0.1% of users get error logging + tracing + Replay integration

Our implementation uses a variant-based configuration:

const sentryVariants: SentryVariant[] = [
    {
        name: 'withReplay',
        threshold: 0.001,
        integrations: [],
    },
    {
        name: 'withBrowserTracing',
        threshold: 0.01,
        integrations: [],
    },
    {
        name: 'basic',
        threshold: 0.1,
        integrations: [],
    },
];

We use a bucketing function to determine which variant applies to the current user:

const selectedVariant = getSentryVariant(config);

Then, we dynamically import only the necessary Sentry modules based on the selected variant:

import { dedupeIntegration } from '@sentry/integrations';

// ...

const selectedVariant = getSentryVariant(config);

if (selectedVariant) {
    const { init } = await import('@sentry/react/esm/sdk');
    const { breadcrumbsIntegration } = await import('@sentry/browser/esm/integrations/breadcrumbs');

    if (selectedVariant.name === 'withBrowserTracing') {
        const { browserTracingIntegration } = await import('@sentry-internal/tracing');
        selectedVariant.integrations = [browserTracingIntegration({ enableInp: true })];
    } else if (selectedVariant.name === 'withReplay') {
        const { browserTracingIntegration } = await import('@sentry-internal/tracing');
        const { replayIntegration } = await import('@sentry/replay');
        selectedVariant.integrations = [browserTracingIntegration({ enableInp: true }), replayIntegration()];
    }

    init({
        // ...
        integrations: [
            dedupeIntegration(),
            breadcrumbsIntegration(),
            ...selectedVariant.integrations,
        ],
    });
}

This approach has been working well for us, but we believe having this functionality built into Sentry or at least having official examples in the documentation would be beneficial for the community. It would:

1. Provide a standardized approach to dynamic loading
2. Reduce implementation complexity for teams
3. Ensure best practices are followed
4. Make it easier to maintain as Sentry evolves

Our implementation could serve as a reference point for the official solution.