-
Notifications
You must be signed in to change notification settings - Fork 36
feat(processWorker): add next version for process worker #1351
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
base: main
Are you sure you want to change the base?
Conversation
| if (context.ProcessStepTypeId.HasValue) | ||
| { | ||
| context.ProcessRepositories.GetInstance<IProcessStepRepository>().AttachAndModifyProcessSteps( | ||
| ModifyStepStatusRange(context.ProcessSteps.Where(step => step.ProcessStepTypeId.Equals(context.ProcessStepTypeId.Value)), ProcessStepStatusId.FAILED, message)); |
Check warning
Code scanning / CodeQL
Dereferenced variable may be null Warning
context.ProcessStepTypeId
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 9 months ago
To fix the issue, we need to ensure that context.ProcessStepTypeId is not null before dereferencing it. This can be achieved by adding a null check before line 137. If context.ProcessStepTypeId is null, the method should either throw an exception or return early, depending on the intended behavior. Since the method already throws exceptions in other cases, throwing an exception when context.ProcessStepTypeId is null would be consistent with the existing design.
-
Copy modified line R134 -
Copy modified line R136 -
Copy modified lines R139-R141
| @@ -133,8 +133,10 @@ | ||
| { | ||
| if (context.ProcessStepTypeId.HasValue) | ||
| if (!context.ProcessStepTypeId.HasValue) | ||
| { | ||
| context.ProcessRepositories.GetInstance<IProcessStepRepository>().AttachAndModifyProcessSteps( | ||
| ModifyStepStatusRange(context.ProcessSteps.Where(step => step.ProcessStepTypeId.Equals(context.ProcessStepTypeId.Value)), ProcessStepStatusId.FAILED, message)); | ||
| throw new ArgumentNullException(nameof(context.ProcessStepTypeId), "ProcessStepTypeId cannot be null."); | ||
| } | ||
|
|
||
| context.ProcessRepositories.GetInstance<IProcessStepRepository>().AttachAndModifyProcessSteps( | ||
| ModifyStepStatusRange(context.ProcessSteps.Where(step => step.ProcessStepTypeId.Equals(context.ProcessStepTypeId.Value)), ProcessStepStatusId.FAILED, message)); | ||
|
|
||
| context.ProcessRepositories.Attach(context.Process); |
| catch (Exception ex) | ||
| { | ||
| Environment.ExitCode = 1; | ||
| _logger.LogError(ex, "processing failed with following Exception {ExceptionMessage}", ex.Message); | ||
| } |
Check notice
Code scanning / CodeQL
Generic catch clause Note
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 9 months ago
To fix the issue, replace the generic catch (Exception ex) clause with specific catch blocks for exceptions that are expected and can be handled appropriately. For unexpected exceptions, rethrow them or handle them in a way that ensures they are not silently suppressed. In this case, we will:
- Catch specific exceptions such as
OperationCanceledException(which is common in async operations with cancellation tokens) and log them appropriately. - Add a fallback
catchblock for other exceptions, but rethrow critical exceptions likeOutOfMemoryExceptionorStackOverflowExceptionthat should not be handled in this context.
-
Copy modified lines R121-R125 -
Copy modified line R128
| @@ -120,6 +120,10 @@ | ||
| } | ||
| catch (Exception ex) | ||
| catch (OperationCanceledException ex) | ||
| { | ||
| _logger.LogWarning(ex, "Operation was canceled: {ExceptionMessage}", ex.Message); | ||
| } | ||
| catch (Exception ex) when (ex is not OutOfMemoryException && ex is not StackOverflowException) | ||
| { | ||
| Environment.ExitCode = 1; | ||
| _logger.LogError(ex, "processing failed with following Exception {ExceptionMessage}", ex.Message); | ||
| _logger.LogError(ex, "Processing failed with the following exception: {ExceptionMessage}", ex.Message); | ||
| } |
ef79fd7 to
2cf3c76
Compare
|


Description
Enhance the process worker to enable the usage of multiple ProcessStepTypeIds
Why
To enable the process worker to be used with multiple ProcessStepTypeIds
Issue
N/A
Checklist