-
Notifications
You must be signed in to change notification settings - Fork 36
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
Non-deterministic System.DateTime usage Roslyn Analyzer #284
Conversation
hm that's weird - the first commit build failed because it failed to compile and find xUnit references. I expected it to just use the common Directory.Build.targets. Then, I manually added the package reference (same
On the other hand, I was able to locally reproduce the issue using |
fixed :) If necessary, I can take the fix and merge it though another PR. Just please let me know 👍 |
73b5a30
to
74b6b3d
Compare
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.
Will this analyzer work for non-function triggers as well? IE:
public class MyOrchestrator : TaskOrchestrator<Input, Output>
{
public async Task<Output> RunAsync(TaskOrchestrationContext context, Input input)
{
var time = DateTime.UtcNow; // will this be checked?
}
}
As it is it doesn't support orchestrators implemented through |
That is fine if it doesn't support it right now - we can review this PR for just the DF scenario. Adding support for the contract in another PR will help keep the PRs small. Just wanted to make sure we were aware of that and tracking that work. |
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.
Thanks for working on this analyzer!
Hi @jviau and @bachuv, I just fixed the code based on the comments above. Thanks for the great suggestions. Now the analyzer supports Durable Functions, TaskOrchestrators and Func based orchestrations. Besides, I moved the strings to a resource file. I might need to increase code coverage based on the new orchestrations support, but as I experiment with other analyzers I will think how to reuse test code and address that too. |
ea30971
to
a3d3799
Compare
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 am not experienced in writing analyzers so can't comment much on the implementation details. I'll look at it further but probably won't hold up the PR on it (as this will be preview).
I think it may be valuable for us to formally detail how our analyzers will follow method call chains that originate in an orchestration. How will this behave with static, instance, interfaces, abstract, etc methods? And as we create this spec we should consider if this could impact non-orchestration scenarios.
What is the expected behavior of the below code:
public static class SomeHelperClass
{
public void HelperMethod() { // uses DateTime.Now }
}
public static class Orchestrations
{
public static void MyOrchestrator([OrchestrationTrigger] TaskOrchestrationContext context)
{
SomeHelperClass.HelperMethod();
}
}
public static class Other
{
public static void OtherMethod([SomeOtherTrigger] Object object)
{
SomeHelperClass.HelperMethod(); // we have a non orchestration use of this method also.
}
}
test/Analyzers.Tests/Orchestration/DateTimeOrchestrationAnalyzerTests.cs
Show resolved
Hide resolved
the previous version wasn't recognizing the latest c# empty collection initializers linting rules
Co-authored-by: Varshitha Bachu <[email protected]>
…sk-dotnet into datetime-analyzer
This analyzer produces the diagnostic
DURABLE0001
, is the equivalent ofDF0101
in the in-proc version of the analyzer. It looks for usages of System.DateTime.(Now|UtcNow|Today) in orchestration methods (or their invocations).It used a stateful analyzer (example) in a base class to gather information about existent orchestration methods and their invocations and, in parallel, the concrete implementation looks for the DateTime usages. Last, after the compilation has ended, it matches if the violations happen in orchestrations and reports them as diagnostics.
I expect to use this abstraction/pattern to look for other usages to implement next rules.
Besides, this PR used the Release Tracking Analyzers and included two additional files to help keep tracking of released diagnostics.