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>
* Finish out effort of adding and enabling blockbuster
* Skip getting addon file size until securetar fixed
* Fix test for devcontainer and blocking I/O
* Fix docker fixture and load_config to post_init
* Use Sentry helper function to report warnings
Don't use Sentry directly but the existing helper function.
* Add pytest that Sentry is by default off
* Address ruff
* Address ruff
Stefan Agner
Mike Degatano