Skip to content
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

Tests relied on FakeTimeProvider failed after upgrading to orleans 8.2.0 #9131

Open
zeinali-ali opened this issue Sep 1, 2024 · 4 comments

Comments

@zeinali-ali
Copy link

In some of our grains we relied on TimeProvider and have written some time-based tests using Microsoft.Orleans.TestingHost but after upgrading to Orleans 8.2.0 it seems there are some unpredictable problems for those test which relied on FakeTimeProvider
we are using this code siloBuilder.Services.AddSingleton<TimeProvider>(FakeTime); to setup a fake time-provider.
and now we are facing some unpredictable problems like:

  1. Implicit subscription not work if we use siloBuilder.Services.AddSingleton<TimeProvider>(FakeTime) .
  2. In some cases FakeTime.SetUtcNow(someTime) took 10min to execute
@ReubenBond
Copy link
Member

Orleans doesn't yet fully support testing with a fake TimeProvider. There are some places in the runtime where we have added support for TimeProvider, but it's not everywhere yet.

@zeinali-ali
Copy link
Author

Yes and that's exactly the problem, as you changed some part of runtime using TimeProvider when we replace TimeProvider with a fake one to test our Grains Behaviors the Orleans-Runtime also take affect and work in an unpredictable behavior.
Isn't it a better practice to use Keyed-Service for TimeProvider in Orleans-Runtime to avoid conflict?

@ReubenBond
Copy link
Member

@zeinali-ali perhaps Keyed DI would be useful in the interim before all timers are replaced. For now, are you able to use keyed DI to inject your fake time provider into your grains? Apologies for the hassle

@zeinali-ali
Copy link
Author

zeinali-ali commented Sep 1, 2024

Sure, we can switch to Keyed-DI to avoid conflict.
However we currently rolled-back to 8.1.0.
I'm just suggesting that a Keyed-DI TimeProvider used in libraries and frameworks can be a better choice to avoid such a conflicts with other libraries and user codes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants