test: stabilize flaky tests

[jpnurmi]

Fixes two distinct issues with assert_timestamp in the test suite:

1. Hard-coded 10s threshold too tight for busy CI

assert_timestamp checked that timestamps were less than 10 seconds old, but tests can exceed that in busy CI environments (e.g. test_breakpad_oom_stdout took 10.6s on the Windows ClangCL CI runner):

FAILED tests/test_integration_stdout.py::test_breakpad_oom_stdout - assert 10.609089 < 10

Replace the arbitrary threshold with a before/after approach: an autouse fixture records the test start time, and the assertion verifies the timestamp falls between test start and now. This eliminates timing sensitivity entirely — it doesn't matter how long the test takes, while still verifying that the timestamp is sensible.

2. Host-device clock skew on Android

The test binary runs on the Android device but pytest runs on the host, so their clocks can differ. Even though CI syncs the emulator clock before test execution, the clock can drift during the run (e.g. NTP correction). Measure the offset per test via adb shell date +%s and adjust timestamps accordingly.

Other changes

• Extract a shared adb() helper into tests/__init__.py to replace duplicated helpers across test files.
• Revert flaky inproc & breakpad OOM stdout tests added in a848058 (keep native & crashpad OOM tests).

[supervacuus]

Revert flaky inproc & breakpad OOM stdout tests added in a848058 (keep native & crashpad OOM tests).

Just saw this:

_______________________________ test_native_oom _______________________________

cmake = <bound method CMake.compile of <tests.cmake.CMake object at 0x000001DFE7C2CA70>>
httpserver = <HTTPServer host=localhost port=49541>

    @pytest.mark.skipif(not has_oom, reason="OOM test unreliable in this environment")
    def test_native_oom(cmake, httpserver):
        """Test OOM crash capture with native backend"""
        tmp_path = cmake(["sentry_example"], {"SENTRY_BACKEND": "native"})
    
        httpserver.expect_request("/api/123456/envelope/").respond_with_data("OK")
    
        run_crash(
            tmp_path,
            "sentry_example",
            ["log", "stdout", "oom"],
            env=dict(os.environ, SENTRY_DSN=make_dsn(httpserver)),
        )
    
        time.sleep(2)
    
        run(
            tmp_path,
            "sentry_example",
            ["log", "no-setup"],
            env=dict(os.environ, SENTRY_DSN=make_dsn(httpserver)),
        )
    
>       assert len(httpserver.log) >= 1
E       assert 0 >= 1
E        +  where 0 = len([])
E        +    where [] = <HTTPServer host=localhost port=49541>.log

tests\test_integration_native.py:120: AssertionError

here: https://github.com/getsentry/sentry-native/actions/runs/23800241648/job/69358394729#step:30:36751
and here: https://github.com/getsentry/sentry-native/actions/runs/23800368814/job/69358858226#step:30:42018

Maybe the OOM tests are generally flaky.

[jpnurmi]

getsentry/sentry-native/actions/runs/23800241648/job/69358394729#step:30:36751

Maybe the OOM tests are generally flaky.

D*mn, even with native. Sorry about that! We've been running similar tests with Crashpad in sentry-unreal without any issues. 🙁

Edit: or maybe the native daemon just needs more tweaks to work reliably under memory pressure... ==> native skipped for now

[supervacuus]

D*mn, even with native. Sorry about that! We've been running similar tests with Crashpad in sentry-unreal without any issues. 🙁

no need to be sorry, i am actually happy when test fail sometimes... not all tests are regression tests, but our red/green fetish completely eliminated any nuance.

Edit: or maybe the native daemon just needs more tweaks to work reliably under memory pressure... ==> native skipped for now

i am not sure this is backend specific, at least not in the handling sense (but could imagine in the timing sense).

[supervacuus]

this is also a new one: https://github.com/getsentry/sentry-native/actions/runs/23802849311/job/69367984681?pr=1614#step:30:410

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: sccache continue-on-error won't degrade gracefully without cmake guard
  • cmake_configure now only sets sccache compiler launcher options when both USE_SCCACHE is set and the sccache binary is available in PATH.

Or push these changes by commenting:

@cursor push fef1bdf1ab

Preview (fef1bdf1ab)

diff --git a/tests/cmake.py b/tests/cmake.py
--- a/tests/cmake.py
+++ b/tests/cmake.py
@@ -130,7 +130,8 @@
     __tracebackhide__ = True
 
     options = dict(options)
-    if os.environ.get("USE_SCCACHE"):
+    has_sccache = os.environ.get("USE_SCCACHE") and shutil.which("sccache")
+    if has_sccache:
         options.update(
             {
                 "CMAKE_C_COMPILER_LAUNCHER": "sccache",

_{This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[jpnurmi]

Great, now the whole infra broke. What a day... 😅

Cloning into 'kcov'...
remote: Internal Server Error
fatal: unable to access 'https://github.com/SimonKagstrom/kcov.git/': The requested URL returned error: 500

fetch https://dl-cdn.alpinelinux.org/alpine/v3.21/main/x86_64/APKINDEX.tar.gz
WARNING: updating https://dl-cdn.alpinelinux.org/alpine/v3.21/main: temporary error (try again later)