ci(miri): skip slow miri tests#2188
Conversation
Clippy Allow Annotation ReportComparing clippy allow annotations between branches:
Summary by Rule
Annotation Counts by File
Annotation Stats by Crate
About This ReportThis report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality. |
📚 Documentation Check Results📦
|
🔒 Cargo Deny Results📦
|
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 537b03f | Docs | Datadog PR Page | Give us feedback! |
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
The run-miri job partitions were taking 20-24 minutes each, dominated by 34 tests nextest flagged as SLOW (many 400-520s). None of these hang or exercise unsafe code Miri exists to check - they're slow because Miri must bytecode-interpret real TLS/HTTP client construction (rustls/ring crypto init, cert-store loading), tokio's executor park/wake machinery, large fixture-driven test loops, or regex-crate compilation/serde overhead on otherwise-trivial inputs.
82d63b7 to
b5da2b8
Compare
| .await; | ||
| } | ||
|
|
||
| #[cfg_attr(miri, ignore)] // tokio executor park/wake overhead is prohibitively slow under Miri |
There was a problem hiding this comment.
could we put this behind a flag so we can have a slow nightly check that does validate them?
There was a problem hiding this comment.
I'm not opposed but I think that should be a different PR as there are already many cfg_attr(miri, ignore) attributes aside from these; git grep "cfg_attr(miri, ignore)" says 460, this PR added just 34 of them. I'm sure many of those are because of performance as well.
What does this PR do?
Adds
#[cfg_attr(miri, ignore)]to 34 SLOW tests.Motivation
The run-miri job partitions were taking 20-24 minutes each, dominated by 34 tests nextest flagged as SLOW (many 400-520s). None of these hang or exercise unsafe code Miri exists to check - they're slow because Miri must bytecode-interpret real TLS/HTTP client construction (rustls/ring crypto init, cert-store loading), tokio's executor park/wake machinery, large fixture-driven test loops, or regex-crate compilation/serde overhead on otherwise-trivial inputs.
Additional Notes
I had claude sonnet 5 do all the analysis and judge the appropriate fixes, and had it leave justifications for why so we can audit that ourselves. They look reasonable to me.
How to test the change?
Same as usual, should just be faster under miri.