This is a new requirement from using the inproc backend in the dotnet runtime (via sentry-android). A detailed explanation of the behavior is here: dotnet/android#9055 (comment)
There are multiple ways to implement this, but since this need is currently only coming from this particular use case and we are a transitive dependency via vanilla sentry-android, we can't expose it as a build parameter. So, I propose adding a boolean option to continue the signal chain at the start (rather than at the end) of the inproc handler. I could also imagine introducing an enum (instead of a boolean) to make this more generic and extensible (something like inproc_handler_strategy...).
I don't know the best approach to passing the option down (sentry-dotnet -> sentry-android -> sentry-native), so I would leave that aspect up to the downstream maintainers.
Another aspect that must be coordinated with downstream maintainers is the actual end-to-end test in a Maui app because my preliminary tests only ran with dotnet on Linux. I have no reason to believe that the runtime behaves differently on Android, but given that Android introduces quite a few offsets to "normal" Linux wrt to signal propagation, this should be verified by updating the sequence of downstream SDKs for an end-to-end test.
cc: @kahest, @bitsandfoxes, @jamescrosswell
This is a new requirement from using the
inprocbackend in the dotnet runtime (viasentry-android). A detailed explanation of the behavior is here: dotnet/android#9055 (comment)There are multiple ways to implement this, but since this need is currently only coming from this particular use case and we are a transitive dependency via vanilla
sentry-android, we can't expose it as a build parameter. So, I propose adding a boolean option to continue the signal chain at the start (rather than at the end) of theinprochandler. I could also imagine introducing an enum (instead of a boolean) to make this more generic and extensible (something likeinproc_handler_strategy...).I don't know the best approach to passing the option down (
sentry-dotnet->sentry-android->sentry-native), so I would leave that aspect up to the downstream maintainers.Another aspect that must be coordinated with downstream maintainers is the actual end-to-end test in a Maui app because my preliminary tests only ran with dotnet on Linux. I have no reason to believe that the runtime behaves differently on Android, but given that Android introduces quite a few offsets to "normal" Linux wrt to signal propagation, this should be verified by updating the sequence of downstream SDKs for an end-to-end test.
cc: @kahest, @bitsandfoxes, @jamescrosswell