Non-deterministic System.DateTime usage Roslyn Analyzer#284
Non-deterministic System.DateTime usage Roslyn Analyzer#284bachuv merged 21 commits intomicrosoft:mainfrom
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
jviau
left a comment
There was a problem hiding this comment.
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. |
bachuv
left a comment
There was a problem hiding this comment.
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.
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 <vabachu@microsoft.com>
…sk-dotnet into datetime-analyzer

This analyzer produces the diagnostic
DURABLE0001, is the equivalent ofDF0101in 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.