Skip to content

Prevent Sentry event feedback loop from warning handler#6700

Open
agners wants to merge 1 commit intomainfrom
filter-sentry-background-thread-warnings
Open

Prevent Sentry event feedback loop from warning handler#6700
agners wants to merge 1 commit intomainfrom
filter-sentry-background-thread-warnings

Conversation

@agners
Copy link
Copy Markdown
Member

@agners agners commented Apr 2, 2026

Proposed change

The custom warning_handler sends warnings to Sentry via capture_exception. When the Sentry SDK's own HTTP transport triggers a warning (e.g. urllib3 InsecureRequestWarning due to broken CA certs), this creates a self-inducing feedback loop: the warning is captured, sent to Sentry, which triggers another warning, and so on.

Skip capture_exception for warnings originating from Sentry SDK background threads (identified by the "sentry-sdk." thread name prefix). Warnings are still logged normally via _LOGGER.warning.

A dedicated test validates that the SDK's BackgroundWorker thread uses the expected naming convention, so any future SDK change will be caught.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (which adds functionality to the supervisor)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to cli pull request:
  • Link to client library pull request:

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • The code has been formatted using Ruff (ruff format supervisor tests)
  • Tests have been added to verify that the new code works.

If API endpoints or add-on configuration are added/changed:

The custom warning_handler sends warnings to Sentry via
capture_exception. When the Sentry SDK's own HTTP transport triggers a
warning (e.g. urllib3 InsecureRequestWarning due to broken CA certs),
this creates a self-inducing feedback loop: the warning is captured,
sent to Sentry, which triggers another warning, and so on.

Skip capture_exception for warnings originating from Sentry SDK
background threads (identified by the "sentry-sdk." thread name
prefix). Warnings are still logged normally via _LOGGER.warning.

A dedicated test validates that the SDK's BackgroundWorker thread uses
the expected naming convention, so any future SDK change will be caught.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@agners agners added the refactor A code change that neither fixes a bug nor adds a feature label Apr 2, 2026
@sentry
Copy link
Copy Markdown

sentry bot commented Apr 2, 2026

Sentry Issue: SUPERVISOR-1HAN

@agners
Copy link
Copy Markdown
Member Author

agners commented Apr 2, 2026

There is only one user which triggers this warning, most likely this is a corrupted Supervisor container image.

Traceback (most recent call last):
InsecureRequestWarning: Unverified HTTPS request is being made to host 'o427061.ingest.sentry.io'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#tls-warnings

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla-signed refactor A code change that neither fixes a bug nor adds a feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants