Timing-dependent library test: deep_owner_expiry_after_existing_timer_preserves_native_last_error

Open
  • Is something wrong?
#8 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
65/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
testing

Research direction

Start with the failing test at src/engine/tests.rs:158 and inspect how its waits interact when tests run in parallel. Make the expectation independent of scheduling while preserving the assertion about the native last error. Confirm the test remains meaningful under parallel execution and passes in repeated full release test runs.

Written by the indexing model from the issue text.

Description

good first issue roadmap

In one of three full runs of cargo test --release --no-fail-fast on Windows 11 this library test failed at src/engine/tests.rs:158 with left: 258 (WAIT_TIMEOUT) against right: 4294967295. It passed in the other two full runs and in five of five runs on its own. The expectation depends on which wait finishes first when the suite runs in parallel. Make the test independent of scheduling without loosening what it asserts about the preserved last error.

Dominant language
Rust
Stars
0
Forks
0
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WikdSolvemProbler/process-tree-guard

All issues in WikdSolvemProbler/process-tree-guard

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.