-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various time related fixes #178
Conversation
21ceaad
to
eabe5ce
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really cool work @nulltoken !
eabe5ce
to
8972628
Compare
Interesting: |
8cd09d5
to
88ff3ed
Compare
Seen this. I'm going to try and dig deeper in this test to understand where this comes from. |
089a055
to
0592032
Compare
@@ -317,6 +319,50 @@ public async Task WhileAwaitingJobTriggeringInstantJobShouldAnywayTriggerCronJob | |||
Assert.Equal(ExecutionState.OrchestrationCompleted, instantOrchestrationEvents[6].State); | |||
Assert.Equal(7, instantOrchestrationEvents.Count); | |||
|
|||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@linkdotnet Below the captured timestamps of a CI failing build.
I'm slightly puzzled by the 24.04 arm result (first below). And the tests don't fail consistently.
Just for comparison, the latest passing 24.04 arm passing build output:
s 0 2000-01-01T00:00:00.0000000+00:00
i 0 2000-01-01T00:00:01.0000000+00:00
s 3 2000-01-01T00:00:01.0000000+00:00
i 2 2000-01-01T00:00:01.0499600+00:00
s 4 2000-01-01T00:00:01.0000000+00:00
i 6 2000-01-01T00:00:01.2258700+00:00
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Compared to the failing one
24.04 arm
s 0 2000-01-01T00:00:00.0000000+00:00
i 0 2000-01-01T00:00:01.0000000+00:00
s 3 2000-01-01T00:00:01.0000000+00:00
i 2 2000-01-01T00:00:01.0000000+00:00 <-----
s 4 2000-01-01T00:00:01.0000000+00:00
i 6 2000-01-01T00:00:01.1924400+00:00
Given i 6 entries values aren't that far one from from another, I can't explain why i 2 hasn't moved forward even a little bit in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've thought about potential concurrency related issues with the FakeTimeProvider, but that seems out of context now that we're running xUnit v3 (https://github.com/dotnet/extensions/blob/main/src/Libraries/Microsoft.Extensions.TimeProvider.Testing/README.md#xunit-v3)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can give NCronJob some time here?
FakeTimer.Advance(TimeSpan.FromSeconds(1));
// Added here not in the source code:
// To enable processing time
await Task.Delay(100);
Guid instantOrchestrationId = provider.GetRequiredService<IInstantJobRegistry>().RunInstantJob<SimpleJob>(token: CancellationToken);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@linkdotnet Ok. I've found a workaround.
Below the latest timings from 24.04 arm
s 0 2000-01-01T00:00:00.0020000+00:00
i 0 2000-01-01T00:00:00.0080000+00:00
s 3 2000-01-01T00:00:00.0100000+00:00
i 2 2000-01-01T00:00:00.0603800+00:00
s 4 2000-01-01T00:00:00.0100000+00:00
i 6 2000-01-01T00:00:00.2286500+00:00
I've tweaked the setup of FakeTimer
to benefit from AutoAdvanceAmount. This more or less simulates time passing between clock access.
a36b29a
to
c441361
Compare
7b84054
to
36c0ea3
Compare
36c0ea3
to
f21ca76
Compare
@linkdotnet Everything seem back to green, now. Does the tweak to FakeTimer fit you? |
Interesting. I am not sure why advancing 1ms will make it seemingly stable. the example you showed also has entries in the sub millisecond precision. Where is this coming from? |
It makes sense as this test is only interested in the order in which events are triggered, not how much time they really took. In the real life, the compute done by the lib takes some time to be done. In this test context, time is frozen and controlled by the test through As every call to
Not everything depends on the Every call to
|
I totally get where you are driving at - I am just "surprised" by those times. So if we use the Anyhow - feel free to merge. My approval still stands :D |
Unless it's moved further through |
Fair - not sure where this is called. |
Pull request description
PR meta checklist
main
branch for codeCode PR specific checklist