Skip to content

UncaughtExceptionHandlerIntegration not working correctly when registered against multiple IHub/Scopes #4429

Open
@armatys

Description

@armatys

Integration

sentry

Java Version

17

Version

8.12.0

Steps to Reproduce

The fix for #3266 introduced a change in behaviour.

In our app, we actually have two independent Sentry instances. One is initialized as usual, by global Sentry[Android].init, and the other is initialized manually in the library code.

The fix in #3398 seems to assume that there's only one Sentry instance. However, I think that the following test should work fine (which it's currently not):

class UncaughtExceptionHandlerIntegrationTest {
    // ...
    val scopes2 = mock<IScopes>()

    // test analogous to existing one (`multiple registrations do not cause the build-up of a tree of UncaughtExceptionHandlerIntegrations`):
    @Test
    fun `multiple registrations`() {
        val initialUncaughtExceptionHandler = Thread.UncaughtExceptionHandler { _, _ -> }

        var currentDefaultHandler: Thread.UncaughtExceptionHandler? = initialUncaughtExceptionHandler

        val handler = mock<UncaughtExceptionHandler>()
        whenever(handler.defaultUncaughtExceptionHandler).thenAnswer { currentDefaultHandler }

        whenever(handler.setDefaultUncaughtExceptionHandler(anyOrNull<Thread.UncaughtExceptionHandler>())).then {
            currentDefaultHandler = it.getArgument(0)
            null
        }

        val integration1 = UncaughtExceptionHandlerIntegration(handler)
        integration1.register(fixture.scopes, fixture.options)

        val integration2 = UncaughtExceptionHandlerIntegration(handler)
        integration2.register(fixture.scopes2, fixture.options)

        assertEquals(currentDefaultHandler, integration2)
        integration2.close()

        assertEquals(integration1, currentDefaultHandler)
    }
}

Expected Result

I.e. if I register two independent UncaughtExceptionHandlerIntegration, while using two different IScopes, both the handlers should form a linked list and remain active.

Actual Result

Only one handler (the last one) is active and when it's closed, it's reverted back to the original one.

Metadata

Metadata

Assignees

Type

No type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions