-
Notifications
You must be signed in to change notification settings - Fork 346
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
Add a Job Analyzer to check if scheduled jobs have corresponding invocation urls #1477
base: release-1.16
Are you sure you want to change the base?
Add a Job Analyzer to check if scheduled jobs have corresponding invocation urls #1477
Conversation
|
Will sign the commits shortly |
8505bf5
to
6d55fe8
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.
Couple of notes
all.sln
Outdated
@@ -155,6 +155,10 @@ Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "JobsSample", "examples\Jobs | |||
EndProject | |||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Dapr.Workflow.Test", "test\Dapr.Workflow.Test\Dapr.Workflow.Test.csproj", "{E90114C6-86FC-43B8-AE5C-D9273CF21FE4}" | |||
EndProject | |||
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Dapr.Jobs.Analyzer", "src\Dapr.Jobs.Analyzer\Dapr.Jobs.Analyzer.csproj", "{28B87C37-4B52-400F-B84D-64F134931BDC}" |
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.
Could you please rename the projects as Dapr.Jobs.Analyzers
and Dapr.Jobs.Analyzers.Tests
so they're consistent with other analyzer projects?
private static readonly DiagnosticDescriptor DaprJobHandlerRule = new DiagnosticDescriptor( | ||
id: "DAPRJOBS0001", | ||
title: "Ensure Post Mapper handler is present for all the Scheduled Jobs", | ||
messageFormat: "There should be a mapping post endpoint for each scheduled job to make sure app receives notifications for all the scheduled jobs", |
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.
Could we reword this to be something like "Job invocations require the MapJobInvocationHandler
be set and configured for each anticipated job on IEndpointRouteBuilder
" with something similar for the title?
} | ||
} | ||
|
||
private static void CheckForEndpointRoute(SyntaxNodeAnalysisContext context, string jobName) |
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.
While this looks like it can determine if an invocation mapping is registered with IEndpointRouteBuilder
or not, it's not actually necessarily if the application never registers a job. Especially as jobs are only invoked on the application that registers them, if it's never registering them, no mapping is necessary as it's never invoked.
Given that, might we look around the assembly and see if there's any use of ScheduleJobAsync
on a DaprJobClient
type first?
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.
Ah, based on your tests, it looks like you're already doing this in line 52 - could you add a comment indicating that's what magic is happening there?
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.
Thats right. If you see the line 52 line there is an if check. We first determine if ScheduleJobAsync
is present as you mentioned and then only call the CheckForEndpointRoute
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.
Few more thoughts
} | ||
|
||
[Fact] | ||
public async Task AnalyzeJobSchedulerHandler_ShouldRaiseDiagnostic_WhenJobHasHasEndpointButDoesNotMapToJobName() |
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.
Seems like this sort of specificity wouldn't end well if the developer passes in a variable to register and subscribe without a constant string.
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.
In addition, string interpolation and concatenation are other cases where this approach may not work. If we want to avoid this complexity, we could simplify the analyzer to check only for the usage of MapDaprScheduledJobHandler. However, this approach has a caveat—we would still generate warnings if developers use IEndpointRouteBuilder directly.
A better approach might be to check for both IEndpointRouteBuilder and MapDaprScheduledJobHandler. This ensures that a mapping exists for the job while also acknowledging that this approach will have some false positive warnings.
I will try to think if there are other approaches available.
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.
The number of places from where the MapPost endpoint can be populated is not exhaustive. It can come from a Config File, other nugets, and string concatenation and interpolations. Going down the current route will lead to large number of False positive which as we were discussing is not a good experience.
I am going to resort back to just checking if MapDaprScheduledJobHandler
is being called when "ScheduleJobAsync" is present. Will push the changes in a bit
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.
Pushed new changes
} | ||
} | ||
|
||
private static void CheckForEndpointRoute(SyntaxNodeAnalysisContext context, string jobName) |
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.
Ah, based on your tests, it looks like you're already doing this in line 52 - could you add a comment indicating that's what magic is happening there?
33ea75e
to
2f377f5
Compare
@WhitWaldo I have addressed all the comments. Please let me know if any additional changes are required. |
Changing the base to merge into |
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.
Change to the analyzer ID, otherwise looks good.
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
Signed-off-by: Siri Varma Vegiraju <[email protected]>
6d2c212
to
d3e5334
Compare
Description
Added a Roslyn Analyzer that checks if every scheduled job has a Job invocation url.
The analyzer checks for patterns like
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #1426
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:
Thank you @ngruson for the initial PRs. It served as a great reference