Skip to content

test: stabilize flaky tests - #2256

Merged
gh-worker-dd-mergequeue-cf854d[bot] merged 3 commits into
mainfrom
r1viollet/stabilize-flaky-tests
Jul 21, 2026
Merged

test: stabilize flaky tests#2256
gh-worker-dd-mergequeue-cf854d[bot] merged 3 commits into
mainfrom
r1viollet/stabilize-flaky-tests

Conversation

@r1viollet

@r1viollet r1viollet commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Skips one ptrace thread-enumeration test under Miri.

Makes async test assertions wait for the expected request instead of relying on fixed sleeps.

Clears the macOS target/panic-abort cache before tests as a short-term workaround for stale cached build artifacts.

Motivation

These flaky tests and the macOS cache issue are currently blocking builds.

Additional Notes

The macOS cache cleanup is intended as a short-term unblocker. A separate draft PR moves panic-abort artifacts outside the cached target tree.

How to test the change?

  • cargo +nightly-2026-02-08 fmt --all -- --check
  • cargo test -q -p libdd-data-pipeline-ffi exporter_send_telemetry_test
  • cargo test -q -p libdd-profiling exporter::exporter_manager::tests -- --nocapture
  • cargo test -q -p libdd-common --features reqwest test_file_dump_captures_http_request -- --nocapture
  • Linux workspace: cargo test -q -p libdd-data-pipeline-ffi exporter_send_telemetry_test repeated 30 times
  • Linux workspace: RUSTUP_TOOLCHAIN=nightly-2026-02-08 MIRIFLAGS="-Zmiri-disable-isolation" cargo miri test -p libdd-crashtracker enumerate_discovers_spawned_thread -- --nocapture

@r1viollet
r1viollet marked this pull request as ready for review July 21, 2026 08:11
@r1viollet
r1viollet requested review from a team as code owners July 21, 2026 08:11
@r1viollet

Copy link
Copy Markdown
Contributor Author

@pr-commenter

pr-commenter Bot commented Jul 21, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-07-21 10:41:53

Comparing candidate commit 059df57 in PR branch r1viollet/stabilize-flaky-tests with baseline commit fb65e46 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 123 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@datadog-prod-us1-5

datadog-prod-us1-5 Bot commented Jul 21, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 93.10%
Overall Coverage: 74.54% (-0.02%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 059df57 | Docs | Datadog PR Page | Give us feedback!

@yannham yannham left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this unblocks, let's merge this 👍

}

#[test]
#[cfg_attr(miri, ignore)]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious, why would miri behave differently wrt to flakiness? Isn't just a red herring (limiting the probability of hitting the issue if we run the test twice as less? Is it a new test that just fails under Miri consistently?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I could not repro this. Clanker has theories about the test that could be an issue:

For this specific test:

  enumerate_discovers_spawned_thread

the test spawns a thread, receives its TID over a channel, then enumerates /proc/self/task and expects that TID to be present.

The channel guarantees the child thread sent its TID, but it does not necessarily prove that Miri/host /proc view will expose that interpreted thread exactly like a normal native Linux thread at that point. Under Miri, threads are simulated/interpreted, while /proc
is an OS interface. With -Zmiri-disable-isolation, Miri allows more host access, but that does not make every host-observable thread assumption robust.

@dd-octo-sts

dd-octo-sts Bot commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.13 MB 8.13 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 88.03 MB 88.04 MB +0% (+1.94 KB) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 99.31 MB 99.32 MB +0% (+3.34 KB) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 10.86 MB 10.86 MB 0% (0 B) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 26.55 MB 26.55 MB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 89.18 KB 89.18 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 191.10 MB 191.09 MB -0% (-8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 1.04 GB 1.04 GB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.65 MB 8.65 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 89.18 KB 89.18 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 25.31 MB 25.31 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 50.49 MB 50.49 MB 0% (0 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 23.13 MB 23.13 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 90.58 KB 90.58 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 195.80 MB 195.79 MB -0% (-16.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 1.03 GB 1.03 GB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.67 MB 6.67 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 90.58 KB 90.58 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 27.22 MB 27.22 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 48.06 MB 48.06 MB 0% (0 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 78.53 MB 78.53 MB +0% (+432 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 9.04 MB 9.04 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 94.02 MB 94.02 MB +0% (+1.00 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.00 MB 11.00 MB 0% (0 B) 👌

@r1viollet
r1viollet requested a review from a team as a code owner July 21, 2026 08:46
with:
cache-targets: true # cache build artifacts
cache-bin: true # cache the ~/.cargo/bin directory
- name: "Clear macOS panic-abort cache"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gyuheon0h this is a workaround, I think we should not be caching this.

@r1viollet

Copy link
Copy Markdown
Contributor Author

@r1viollet
r1viollet requested a review from a team as a code owner July 21, 2026 10:11
@r1viollet

Copy link
Copy Markdown
Contributor Author

@r1viollet

Copy link
Copy Markdown
Contributor Author

/merge

@gh-worker-devflow-routing-ef8351

gh-worker-devflow-routing-ef8351 Bot commented Jul 21, 2026

Copy link
Copy Markdown

View all feedbacks in Devflow UI.

2026-07-21 10:15:13 UTC ℹ️ Start processing command /merge


2026-07-21 10:15:20 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.


2026-07-21 10:58:12 UTC ℹ️ MergeQueue: merge request added to the queue

The expected merge time in main is approximately 1h (p90).


2026-07-21 11:40:03 UTC ℹ️ MergeQueue: This merge request was merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants