feat(asyncio): Add on-demand way to enable AsyncioIntegration

[sentrivana]

Initializing the SDK in an async environment can be a challenge, since the requirement to initialize as early as possible might clash with the requirement to initialize when there's an event loop running, if one wants to use the AsyncioIntegration. These sort of scenarios would benefit from a dedicated way to activate the integration after init() has been called.

Supersedes the needlessly more general #5285

[sentrivana]

I'm explicitly not allowing overwriting the old integration with the new one so that we don't end up double patching the event loop. We could add extra logic to restore the original code and re-patch that, but it seems like that's a lot of extra work for a usecase no one will probably need.

[cursor]

Race condition allows double-patching of asyncio event loop

Medium Severity

The _enable_integration function checks client.integrations while holding the lock, but the assignment to client.integrations in enable_asyncio_integration happens after the lock is released. If two threads call enable_asyncio_integration concurrently, both can pass the check (since client.integrations is still empty), causing setup_once() and patch_asyncio() to be called twice. This results in double-wrapping the task factory, directly contradicting the stated goal of preventing double patching. The check could use _installed_integrations (which is updated inside the lock), or the assignment to client.integrations could be moved inside the lock.

Additional Locations (1)

• sentry_sdk/integrations/asyncio.py#L175-L176

 

[cursor]

Missing global check allows duplicate setup_once() after re-init

Medium Severity

The _enable_integration function only checks client.integrations (specific to the current client), but doesn't check _installed_integrations (the global set tracking all successfully installed integrations). The original setup_integrations uses _processed_integrations to prevent calling setup_once() multiple times since it's a static method that patches global state. When a user re-initializes Sentry (calling init() again), the new client has an empty integrations dict, so _enable_integration will call setup_once() again even though the event loop was already patched by a previous client, causing double instrumentation.