Fix flaky SdkInitTests

[adinauer]

📜 Description

• Set a mocked online status provider that always returns CONNECTED
• Set lower connectionTimeoutMillis and readTimeoutMillis (500ms)

Also handle RejectedExecutionException in SystemEventsBreadcrumbIntegration

💡 Motivation and Context

Tests could make Sentry think it's offline due to NO_RESPONSE thus directly using offline disk cache and never decrementing relayIdlingResource. Or they would run into the default timeout of 30s whereas the test only waits for 10s.

💚 How did you test it?

📝 Checklist

• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[adinauer]

• Fix flaky SdkInitTests #4661 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- Fix flaky SdkInitTests ([#4661](https://github.com/getsentry/sentry-java/pull/4661))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description or adding a skip-changelog label.

Generated by 🚫 dangerJS against d1184ba

[cursor]

Bug: Receiver Cleanup Fails on RejectedExecutionException

When unregisterReceiver() catches a RejectedExecutionException, the essential cleanup logic (unregistering the receiver, nullifying its reference, and updating isStopped) is skipped. This leaves the receiver registered with the Android system and the integration in an inconsistent state, potentially causing resource leaks.

 

[romtsn]

I think this is legit - could you extract the logic into unregisterReceiverInternal or something and then call it in the catch block? In that case I think it's fine to still do it on the calling thread

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	526.14 ms	620.27 ms	94.12 ms
Size	1.58 MiB	2.10 MiB	531.12 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
ee747ae	386.94 ms	431.43 ms	44.49 ms
ee747ae	405.43 ms	485.70 ms	80.28 ms
ee747ae	415.92 ms	470.15 ms	54.23 ms
ee747ae	358.21 ms	389.41 ms	31.20 ms
ee747ae	374.71 ms	455.18 ms	80.47 ms
ee747ae	396.82 ms	441.67 ms	44.86 ms
ee747ae	554.98 ms	611.50 ms	56.52 ms
ee747ae	382.73 ms	435.41 ms	52.68 ms
ee747ae	400.46 ms	423.61 ms	23.15 ms
ee747ae	357.79 ms	421.84 ms	64.05 ms

App size

Revision	Plain	With Sentry	Diff
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB

[romtsn]

hm, wondering if it's still going to fail because the device does not have internet connection, but we're saying here that it does? Shall we also try to enable it via e.g. executing adb shell svc wifi enable or something like that?

[stefanosiano]

i don't think it's a problem, because it's sending to localhost anyway, except for a single test (EnvelopeTests.sendProfiledTransaction) that we may even remove
But we block sending the envelopes if there's no connection, so this is good

[romtsn]

LGTM, nice finds!

[stefanosiano]

not sure if these make any actual difference

      options.readTimeoutMillis = 500
      options.connectionTimeoutMillis = 500

The only case where we use the addTimeoutResponse() is when we want to test the envelope is written to disk when the SDK restart, so it shouldn't make any difference for all the other tests
Also, it could potentially make the SDK restart tests unreliable, since it would have 500 milliseconds to send the envelope or save to disk, making it test for the wrong thing (we want to test the SDK writes to disk on SDK restart, not on connection timeout)