fix(sdk): skip current_exe() under Miri in default service.name fallback

[scottgerring]

Fixes #3523.

std::env::current_exe() aborts under Miri isolation instead of returning Err, so the existing .ok() fallback in SdkProvidedResourceDetector was unreachable, causing any test that constructed a default SDK provider to abort under Miri.

Extract the fallback into default_service_name() and short-circuit to "unknown_service" when cfg!(miri) is set, preserving the normal unknown_service:<process.executable.name> behaviour outside Miri.

Also adds a targeted Miri smoke test (tests/miri_smoke.rs) and a minimal CI job that runs only that test under nightly Miri.

Design discussion issue (if applicable) #

Changes

Please provide a brief description of the changes here.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

❌ Patch coverage is 89.47368% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.9%. Comparing base (f7b0dd9) to head (013f14f).
⚠️ Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
opentelemetry-sdk/src/resource/env.rs	89.4%	2 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff           @@
##            main   #3525    +/-   ##
======================================
  Coverage   82.9%   82.9%            
======================================
  Files        130     130            
  Lines      27350   27484   +134     
======================================
+ Hits       22675   22800   +125     
- Misses      4675    4684     +9     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[scottgerring]

this was getting a bit long so factored it out

[scottgerring]

super basic 'run miri at all' smoke test to try catch these in the future

[cijothomas]

lets run all crates, not just sdk?

[scottgerring]

i've not used miri much before, so I had a look at doing this; here's what i've found trying to run cargo miri test against each crate in the workspace using the same arguments as scripts/test.sh:

Crate	Tests	Pass	Result	Failure reason
opentelemetry	55	17	❌ aborts	kqueue - single #[tokio::test] for async context propagation
opentelemetry-sdk	387	13	❌ aborts	clock_gettime - batch processor tests touch std::time
opentelemetry-http	5	5	✅ clean	-
opentelemetry-appender-log	6	1	❌ aborts	clock_gettime - first test reads system time
opentelemetry-semantic-conventions	0	0	✅ clean	-
opentelemetry-stdout	0	0	✅ clean	-
opentelemetry-appender-tracing	15	0	❌ aborts	clock_gettime - hits on first test
opentelemetry-jaeger-propagator	18	18	✅ clean	-
opentelemetry-otlp	131	6	❌ aborts	llvm.aarch64.crc32b - gzip CRC32 uses an aarch64 hardware intrinsic Miri won't execute
opentelemetry-proto	14	2	❌ aborts	clock_gettime
opentelemetry-zipkin	13	7	❌ aborts	clock_gettime
opentelemetry-prometheus	2	2	✅ clean	-

The 8 ignored SDK tests (tokio runtime + self-diagnostics) and the opentelemetry --no-default-features run all fail with the same clock_gettime / kqueue errors.

TL;DR - things that break

1. **clock_gettime - Miri's default isolation blocks all system clock calls. Anything that creates a std::time::Instant, SystemTime, or uses tokio's timer hits this. -Zmiri-disable-isolation unblocks the syscall but causes batch/async tests to hang indefinitely, because they also require real thread scheduling.

2. kqueue - One #[tokio::test] in opentelemetry for async context propagation. Same root cause as the smoke.rs failure in opentelemetry-otlp.

3. llvm.aarch64.crc32b - The OTLP gzip compression test uses a CRC32 hardware intrinsic on aarch64. Architecture-specific; might pass on x86_64 CI!

The crates that pass cleanly are those that deal with pure data transformation: header/propagation format parsing, semantic convention constants. The crates with the most test value - SDK processors, appenders, OTLP - all depend on std::time or tokio, which are fundamentally incompatible with Miri's isolation model.

The miri_smoke test in opentelemetry-sdk avoids time and async entirely, exercising only the initialisation path where the original current_exe() bug lived. To expand Miri coverage to other crates we'd need to write tests specifically to avoid time, async, and I/O.

[scottgerring]

Effectively stuff that doesn't seem like it's going to benefit from miri is testable (logic, mapping - like opentelemetry-jaeger-propagator ). The crates where Miri would add genuine value (processors, exporters) are blocked by clock_gettime and tokio's I/O driver before they can run a single meaningful test.

If someone else has more experience here with miri i'd love to hear about it, but for now I suggest we stick with a basic smoke test that catches this regression and keep an eye on what we might improve later.

[lalitb]

LGTM. Thanks.

[scottgerring]

@cijothomas this should be good to go!

[cijothomas]

We've never explicitly committed to Miri support in this project. The Miri guard makes sense as a tactical fix, but the CI job implicitly makes Miri a supported use case going forward, which means future contributors would need to be careful about any new syscall-touching code too.

Should we make that commitment explicitly, or just land the tactical fix for now and revisit Miri CI as a separate decision?

[scottgerring]

We've never explicitly committed to Miri support in this project. The Miri guard makes sense as a tactical fix, but the CI job implicitly makes Miri a supported use case going forward, which means future contributors would need to be careful about any new syscall-touching code too.

Should we make that commitment explicitly, or just land the tactical fix for now and revisit Miri CI as a separate decision?

@cijothomas supporting miri properly would be a big deal and we should absolutely defer that for the moment - there's a bunch more pressing stuff to land imho - i've created #3525 to track that.

In the meantime ACK that the CI job might send a funny signal - that having any "miri looking" stuff might seem like a commitment. To that end, i've added some comments around the CI job and the test itself pointing at that issue. We could always drop the test/CI completely, but I kinda like having this regression catch as a beachhead for future miri support.

LMK what you think

[cijothomas]

We've never explicitly committed to Miri support in this project. The Miri guard makes sense as a tactical fix, but the CI job implicitly makes Miri a supported use case going forward, which means future contributors would need to be careful about any new syscall-touching code too.
Should we make that commitment explicitly, or just land the tactical fix for now and revisit Miri CI as a separate decision?

@cijothomas supporting miri properly would be a big deal and we should absolutely defer that for the moment - there's a bunch more pressing stuff to land imho - i've created #3525 to track that.

In the meantime ACK that the CI job might send a funny signal - that having any "miri looking" stuff might seem like a commitment. To that end, i've added some comments around the CI job and the test itself pointing at that issue. We could always drop the test/CI completely, but I kinda like having this regression catch as a beachhead for future miri support.

LMK what you think

Thanks. I'll open a similar issue to track related things (like wasm, no-std etc)