Repository navigation
test(daemon): plant a scheduler owner only once its task ended - #4182
Merged
Merged
Conversation
The concurrent re-enable test planted a finished scheduler owner, but its barrier was a signal sent from inside the task body. The native runtime marks the task finished only after that body returns, so a loaded worker left the owner reading as live. Both re-enables then notified it and the test saw (RunningNotified, RunningNotified), which is correct production behavior for a live owner. Await the planted task's outcome before inserting it, and print the outcome pair when the final assertion fails. Fixes #4165
|
ScriptedAlchemy
enabled auto-merge
October 17, 2026 04:16
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4165.
Root cause
The test was wrong. Production was not.
The test plants a finished scheduler owner, then runs two concurrent re-enables. Its barrier was a oneshot sent from inside the planted task's body. That signal comes before the task ends. The native runtime marks the task finished only after the body returns. On a loaded worker, the re-enables can run in that window.
observed_scheduler_lifecyclethen reads the planted owner asRunning, so both re-enables returnRunningNotified. That is correct for a live owner. The earlier assertions still pass because the planted task still reads as live. Only the final pair assertion fails, as the issue reports.Change
NativeTaskOutcome::Completedbefore it inserts the handle. The oneshot is gone.Verification
(RunningNotified, RunningNotified)at the final assertion. The fixed barrier passes with the same delay.observed_scheduler_lifecycleignore a finished task, which breaks finished-owner replacement. The test fails at the live-scheduler assertion.--runs_per_test=30 --local_test_jobs=20 --run_under=taskset -c 0-7).//crates/tracedecay:daemon_suiteandrustfmt_check_2024passed. A full//crates/tracedecay:unit_testrun here fails only on test(daemon): replayed hook admission test sees Backpressured #4172 (fixed in test(daemon): replay a settled hook failure once, not per poll #4181). With test(daemon): replay a settled hook failure once, not per poll #4181's commit applied on top, it passed two full runs (901/901), and clippy (--config=clippy) passed.