ref(insights): replace useRouter with specific hooks in spanSummary sampleList

[evanpurkhiser]

Part of the React Router 6 cleanup — replaces useRouter() with specific hooks (useNavigate, useLocation, useParams, etc.)

[github-actions]

🚨 Warning: This pull request contains Frontend and Backend changes!

It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently.

Have questions? Please ask in the #discuss-dev-infra channel.

In general, the fix is to avoid sending the raw exception message back to the client. Instead, log the exception (including stack trace / message) on the server, and return a generic, non‑sensitive error message to the user. This preserves debuggability while preventing information exposure.

For this specific code:

• In _initialize_pipeline, the except IntegrationPipelineError as e: block currently returns {"detail": str(e)} with different status codes based on e.not_found.
• We should:
  • Log the exception using the existing logger defined at the top of the file, ideally with logger.exception so the stack trace is captured.
  • Return a generic error message string that does not include e’s content.
  • Preserve the existing behavior of using 404 vs 400 depending on e.not_found, since that is part of the API contract and does not itself leak sensitive information.

Concretely, in src/sentry/api/endpoints/organization_pipeline.py, around lines 112–118:

• Replace return Response({"detail": str(e)}, status=404 if e.not_found else 400) with:
  • A logger.exception call that logs that initialization failed and includes provider_id for context.
  • A Response that has either:
    • a 404 status with a generic “Resource not found.”‑style message, or
    • a 400 status with a generic “Failed to initialize integration pipeline.”‑style message.
• No new imports are needed; logger is already defined and uses logging.getLogger(__name__).

This preserves functionality (status codes and control flow) while ensuring the client never sees the raw exception message.

---

In general, to fix this type of problem you should avoid including raw exception messages in responses that can be seen by external users. Instead, log the exception details on the server side (so developers can debug), and raise or return a generic, non-sensitive error message to the client.

For this specific code, the best fix without changing existing functionality is to keep raising a ValidationError from validate_jwt, but change its message to a generic one that does not interpolate e. If the project has a central logging mechanism (Django’s logger or Sentry itself), we could additionally log e for debugging, but the user-visible string should remain generic. Since the snippet doesn’t show any logger imports, and we are asked to avoid unwarranted assumptions, we’ll implement the minimal fix: replace raise ValidationError(f"Unable to verify installation: {e}") from e with raise ValidationError("Unable to verify installation.") from e. This preserves the behavior of signaling a validation failure to the client but removes exposure of internal error information.

The change is confined to src/sentry/integrations/bitbucket/integration.py, in the BitbucketVerifySerializer.validate_jwt method, lines 214–215 in the provided snippet. No new imports or additional methods are strictly necessary for this minimal fix.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Test expects "stay" response but serializer raises ValidationError

Medium Severity

The test_oauth_step_missing_fields test expects status_code == 200 with resp.data["status"] == "stay" when submitting empty data to the OAuth step. However, api_advance calls serializer.is_valid(raise_exception=True), so the OAuthLoginSerializer (which has code and state as required=True) will raise a DRF ValidationError that gets caught by DRF's exception handler, returning a 400 with raw serializer errors — never reaching handle_post to produce a "stay" PipelineStepResult. The equivalent GitLab and GHE tests correctly expect status_code == 400 with raw error fields for the same scenario. This test will fail as written.

Additional Locations (1)

• src/sentry/pipeline/base.py#L313-L320

 

[github-actions]

Backend Test Failures

Failures on b9448b8 in this run:

tests/sentry/integrations/github/test_integration_api_pipeline.py::GitHubIntegrationApiPipelineTest::test_oauth_exchange_failure — log

tests/sentry/integrations/github/test_integration_api_pipeline.py:355: in test_oauth_exchange_failure
    assert resp.status_code == 200
E   assert 400 == 200
E    +  where 400 = <Response status_code=400, "application/json">.status_code

tests/sentry/integrations/github/test_integration_api_pipeline.py::GitHubIntegrationApiPipelineTest::test_oauth_step_missing_fields — log

tests/sentry/integrations/github/test_integration_api_pipeline.py:253: in test_oauth_step_missing_fields
    assert resp.status_code == 200
E   assert 400 == 200
E    +  where 400 = <Response status_code=400, "application/json">.status_code

tests/sentry/integrations/github/test_integration_api_pipeline.py::GitHubIntegrationApiPipelineTest::test_oauth_step_invalid_state — log

tests/sentry/integrations/github/test_integration_api_pipeline.py:245: in test_oauth_step_invalid_state
    assert resp.status_code == 200
E   assert 400 == 200
E    +  where 400 = <Response status_code=400, "application/json">.status_code

[sentry-warden]

UnicodeDecodeError unhandled in OAuth token exchange

The body.decode("utf-8") call can raise UnicodeDecodeError if an external OAuth provider returns form-urlencoded data with invalid UTF-8 bytes. The current exception handler only catches orjson.JSONDecodeError, allowing UnicodeDecodeError to propagate as an unhandled 500 error. This matches the Data Parsing pattern (Check 8) where external data parsing lacks complete error handling.

Verification

Read src/sentry/identity/oauth2.py lines 477-495 to confirm the try/except only catches orjson.JSONDecodeError. Verified safe_urlread returns bytes (src/sentry/http.py line 120). Confirmed UnicodeDecodeError is handled elsewhere in the codebase for similar external data parsing (e.g., src/sentry/integrations/github/platform_detection.py).

Also found at 1 additional location

• src/sentry/integrations/github_enterprise/integration.py:571-572

Identified by Warden sentry-backend-bugs · 7ZK-SG2

[evanpurkhiser]

damnit