Request: Add configuration option to capture 302 redirect transactions

[peter-ecp]

Problem Statement

The Sentry Node SDK currently drops HTTP transactions with 302 status codes by default (introduced in v9.x via #16972). While this reduces noise for most applications, it creates a significant blind spot for SSO (Single Sign-On) applications and other authentication services where 302 redirects represent the primary and most critical code paths.
Use Case
I'm running an SSO authentication API where the main flow is:

1. Receive SAML assertion at POST /auth/assert
2. Validate credentials (includes multiple database queries)
3. Create session and redirect user (302) to the target application
   The problem: Despite enabling profiling with profilesSampleRate: 1.0, no profiling data is captured for these critical routes because they return 302 status codes. The logs show:
   [Profiling] started profiling transaction: POST /auth/assert
   [Profiling] stopped profiling of transaction: POST /auth/assert
   Dropping transaction due to status code 302
   Event processor "Http" dropped event
   The profiling data is being collected but then immediately discarded.

Solution Brainstorm

Proposed Solution
Add a configuration option to control which status codes are filtered, similar to how 300 and 304 were re-enabled in v10.13.0 (#17686):
javascript

Sentry.init({
  dsn: "...",
  integrations: [
    nodeProfilingIntegration(),
    Sentry.httpIntegration({
      // Option 1: Capture specific status codes
      captureStatusCodes: [200, 201, 300, 301, 302, 303, 307, 308, 400, 500],
      
      // OR Option 2: Disable status code filtering entirely
      filterStatusCodes: false,
    }),
  ],
  tracesSampleRate: 1.0,
  profilesSampleRate: 1.0,
});

Workarounds Attempted

1. beforeSendTransaction hook - Not called because the Http event processor drops the transaction first
2. Removing the Http integration - Auto-instrumentation still creates and drops transactions
3. Manual transaction creation with startSpanManual - Creates duplicate transactions that both get dropped
4. Downgrading to v7 - Not viable due to Node.js version compatibility issues with @sentry/profiling-node

Additional Context

Impact
This affects any application where redirects are business-critical:
• SSO/authentication services (SAML, OAuth, OIDC)
• API gateways that redirect to different services
• URL shorteners
• Applications implementing the Post/Redirect/Get pattern
For these applications, the most performance-critical code paths produce zero profiling data.
Additional Context
• Version: @sentry/node@10.26.0 and @sentry/profiling-node@10.26.0
• The issue exists in all v9.x and v10.x versions
• Related: #17686 (which added 300/304 support, showing there's precedent for making redirect status codes configurable)
Example Debug Output
[Tracing] Starting sampled root span
op: http.server
name: POST /auth/assert
[Profiling] started profiling transaction: POST /auth/assert
... (database queries and business logic spans) ...
[Profiling] stopped profiling of transaction: POST /auth/assert
Dropping transaction due to status code 302
Event processor "Http" dropped event
An event processor returned null, will not send event.
Would appreciate any guidance on how to capture these transactions, or consideration for adding this configuration option in a future release. Thank you!

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

[linear]

JS-1297

[andreiborza]

Hey @peter-ecp, thanks for writing in.

You should be able to set dropSpansForIncomingRequestStatusCodes of the http integration, something like:

Sentry.init({
   dsn: '...',
   integrations: [
      Sentry.httpIntegration({
		 // Explicitly exclude `302` from the range
         dropSpansForIncomingRequestStatusCodes: [[401, 404], [301, 301], [303, 303], [305, 399]],
       }),
   ]
})

Does that work for you?