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

Add a Job Analyzer to check if scheduled jobs have corresponding invocation urls #1477

Open
wants to merge 10 commits into
base: release-1.16
Choose a base branch
from

Conversation

siri-varma
Copy link
Contributor

@siri-varma siri-varma commented Feb 28, 2025

Description

Added a Roslyn Analyzer that checks if every scheduled job has a Job invocation url.

The analyzer checks for patterns like

  • /job/123
  • /job/{jobName}

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:

  • Code compiles correctly
  • Created/updated tests
  • Extended the documentation

Thank you @ngruson for the initial PRs. It served as a great reference

@siri-varma siri-varma requested review from a team as code owners February 28, 2025 22:22
@siri-varma siri-varma changed the title Users/svegiraju/job analyzer Add a Job Analyzer to check if scheduled jobs have corresponding invocation urls Feb 28, 2025
@WhitWaldo WhitWaldo added this to the v1.16 milestone Feb 28, 2025
@siri-varma
Copy link
Contributor Author

  • In the Dapr Jobs client, we have MapDaprScheduledJobHandler. However, the analyzer still throws an error because it is unable to detect the MapPost call within the method. I think this is what you were mentioning about @WhitWaldo. If we need to address this scenario, I can add a separate analyzer that checks for the presence of MapDaprScheduledJobHandler.

@siri-varma
Copy link
Contributor Author

Will sign the commits shortly

@siri-varma siri-varma force-pushed the users/svegiraju/job-analyzer branch from 8505bf5 to 6d55fe8 Compare February 28, 2025 22:34
Copy link
Contributor

@WhitWaldo WhitWaldo left a 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}"
Copy link
Contributor

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",
Copy link
Contributor

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)
Copy link
Contributor

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?

Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/dapr/dotnet-sdk/pull/1477/files#diff-95a4bc519fc6b5c49452acf4c17caa549c2f54e1e114de4431bf24ef32d51c3bR52

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

Copy link
Contributor

@WhitWaldo WhitWaldo left a 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()
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@siri-varma siri-varma Mar 3, 2025

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

Copy link
Contributor Author

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)
Copy link
Contributor

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?

@siri-varma siri-varma force-pushed the users/svegiraju/job-analyzer branch from 33ea75e to 2f377f5 Compare March 3, 2025 20:52
@siri-varma siri-varma requested a review from WhitWaldo March 12, 2025 05:30
@siri-varma
Copy link
Contributor Author

@WhitWaldo I have addressed all the comments. Please let me know if any additional changes are required.

@WhitWaldo WhitWaldo changed the base branch from master to release-1.16 March 17, 2025 01:27
@WhitWaldo
Copy link
Contributor

Changing the base to merge into release-1.16 instead of master.

Copy link
Contributor

@WhitWaldo WhitWaldo left a 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.

svegiraju-microsoft and others added 10 commits March 17, 2025 07:47
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]>
@siri-varma siri-varma force-pushed the users/svegiraju/job-analyzer branch from 6d2c212 to d3e5334 Compare March 17, 2025 14:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add analyzers that help prevent developer gotchas
3 participants