[ETASK-29] Menu item creation in menu#339
Merged
Merged
Conversation
- handle frontend actions on task events
Walkthrough
ChangesFront Action Execution in Task Services
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Kovy95
previously approved these changes
Jun 19, 2026
- update quotes
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@projects/netgrif-components-core/src/lib/task/services/assign-task.service.ts`:
- Around line 130-135: The _frontActionService.runAll(frontActions) call is not
isolated from the success flow and can abort execution if any front action
throws an error, preventing the subsequent reload/forceReload and
completeActions from running. Wrap the runAll() call in a try-catch block to
ensure that even if front action execution fails, the task operations
(forceReload or reload) and the completeActions method still execute to maintain
the proper event progression after a successful backend response.
In
`@projects/netgrif-components-core/src/lib/task/services/cancel-task.service.ts`:
- Around line 132-137: The front action execution via
this._frontActionService.runAll(frontActions) can throw an error and prevent the
subsequent reload and completeActions from being called, leaving cancel
lifecycle callbacks unresolved. Wrap the front action execution in a try-catch
block to ensure that if a front action fails, the error is handled gracefully
and the reload (either forceReload or reload via this._taskOperations) and the
completeActions method with afterAction, nextEvent, and outcomeResource.outcome
are still executed to properly complete the cancel lifecycle.
In
`@projects/netgrif-components-core/src/lib/task/services/finish-task.service.ts`:
- Around line 146-152: The _frontActionService.runAll(frontActions) call on line
148 is not wrapped in error handling, which means any uncaught exceptions from
runAll will prevent the subsequent calls to _taskOperations.reload(),
completeActions(), and _taskOperations.close() from executing, leaving the
system in a broken post-finish state. Wrap the runAll() invocation in a
try-catch block to isolate front-action failures while ensuring that reload,
completeActions, and close operations continue to execute regardless of whether
runAll throws an exception.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3575f961-3faa-44d7-b785-94891c7efe6b
📒 Files selected for processing (3)
projects/netgrif-components-core/src/lib/task/services/assign-task.service.tsprojects/netgrif-components-core/src/lib/task/services/cancel-task.service.tsprojects/netgrif-components-core/src/lib/task/services/finish-task.service.ts
Comment on lines
+130
to
135
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | ||
| if (frontActions?.length > 0) { | ||
| this._frontActionService.runAll(frontActions); | ||
| } | ||
| forceReload ? this._taskOperations.forceReload() : this._taskOperations.reload(); | ||
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as AssignTaskEventOutcome); |
There was a problem hiding this comment.
Guard front-action execution so success flow cannot be aborted.
On Line 132, runAll() is not isolated; if any front action throws (including unknown action-id dispatch), the code after it won’t run (reload/forceReload, completeActions, snackbar), breaking event progression despite a successful backend response.
Proposed fix
const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome);
if (frontActions?.length > 0) {
- this._frontActionService.runAll(frontActions);
+ try {
+ this._frontActionService.runAll(frontActions);
+ } catch (e) {
+ this._log.error('Executing front actions after assign failed', e);
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | |
| if (frontActions?.length > 0) { | |
| this._frontActionService.runAll(frontActions); | |
| } | |
| forceReload ? this._taskOperations.forceReload() : this._taskOperations.reload(); | |
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as AssignTaskEventOutcome); | |
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | |
| if (frontActions?.length > 0) { | |
| try { | |
| this._frontActionService.runAll(frontActions); | |
| } catch (e) { | |
| this._log.error('Executing front actions after assign failed', e); | |
| } | |
| } | |
| forceReload ? this._taskOperations.forceReload() : this._taskOperations.reload(); | |
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as AssignTaskEventOutcome); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@projects/netgrif-components-core/src/lib/task/services/assign-task.service.ts`
around lines 130 - 135, The _frontActionService.runAll(frontActions) call is not
isolated from the success flow and can abort execution if any front action
throws an error, preventing the subsequent reload/forceReload and
completeActions from running. Wrap the runAll() call in a try-catch block to
ensure that even if front action execution fails, the task operations
(forceReload or reload) and the completeActions method still execute to maintain
the proper event progression after a successful backend response.
Comment on lines
+132
to
137
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | ||
| if (frontActions?.length > 0) { | ||
| this._frontActionService.runAll(frontActions); | ||
| } | ||
| forceReload ? this._taskOperations.forceReload() : this._taskOperations.reload(); | ||
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as CancelTaskEventOutcome); |
There was a problem hiding this comment.
Protect cancel success path from front-action runtime failures.
On Line 134, a thrown front action can interrupt the success branch before reload and completeActions, leaving cancel lifecycle callbacks unresolved.
Proposed fix
const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome);
if (frontActions?.length > 0) {
- this._frontActionService.runAll(frontActions);
+ try {
+ this._frontActionService.runAll(frontActions);
+ } catch (e) {
+ this._log.error('Executing front actions after cancel failed', e);
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | |
| if (frontActions?.length > 0) { | |
| this._frontActionService.runAll(frontActions); | |
| } | |
| forceReload ? this._taskOperations.forceReload() : this._taskOperations.reload(); | |
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as CancelTaskEventOutcome); | |
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | |
| if (frontActions?.length > 0) { | |
| try { | |
| this._frontActionService.runAll(frontActions); | |
| } catch (e) { | |
| this._log.error('Executing front actions after cancel failed', e); | |
| } | |
| } | |
| forceReload ? this._taskOperations.forceReload() : this._taskOperations.reload(); | |
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as CancelTaskEventOutcome); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@projects/netgrif-components-core/src/lib/task/services/cancel-task.service.ts`
around lines 132 - 137, The front action execution via
this._frontActionService.runAll(frontActions) can throw an error and prevent the
subsequent reload and completeActions from being called, leaving cancel
lifecycle callbacks unresolved. Wrap the front action execution in a try-catch
block to ensure that if a front action fails, the error is handled gracefully
and the reload (either forceReload or reload via this._taskOperations) and the
completeActions method with afterAction, nextEvent, and outcomeResource.outcome
are still executed to properly complete the cancel lifecycle.
Comment on lines
+146
to
152
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | ||
| if (frontActions?.length > 0) { | ||
| this._frontActionService.runAll(frontActions); | ||
| } | ||
| this._taskOperations.reload(); | ||
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as FinishTaskEventOutcome); | ||
| this._taskOperations.close(); |
There was a problem hiding this comment.
Isolate front-action failures in finish success handling.
On Line 148, uncaught exceptions from runAll() can prevent reload, completeActions, and close, causing a broken post-finish state after a successful backend finish.
Proposed fix
const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome);
if (frontActions?.length > 0) {
- this._frontActionService.runAll(frontActions);
+ try {
+ this._frontActionService.runAll(frontActions);
+ } catch (e) {
+ this._log.error('Executing front actions after finish failed', e);
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | |
| if (frontActions?.length > 0) { | |
| this._frontActionService.runAll(frontActions); | |
| } | |
| this._taskOperations.reload(); | |
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as FinishTaskEventOutcome); | |
| this._taskOperations.close(); | |
| const frontActions: Array<FrontAction> = this._eventService.parseFrontActionsFromOutcomeTree(outcomeResource.outcome); | |
| if (frontActions?.length > 0) { | |
| try { | |
| this._frontActionService.runAll(frontActions); | |
| } catch (e) { | |
| this._log.error('Executing front actions after finish failed', e); | |
| } | |
| } | |
| this._taskOperations.reload(); | |
| this.completeActions(afterAction, nextEvent, true, outcomeResource.outcome as FinishTaskEventOutcome); | |
| this._taskOperations.close(); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@projects/netgrif-components-core/src/lib/task/services/finish-task.service.ts`
around lines 146 - 152, The _frontActionService.runAll(frontActions) call on
line 148 is not wrapped in error handling, which means any uncaught exceptions
from runAll will prevent the subsequent calls to _taskOperations.reload(),
completeActions(), and _taskOperations.close() from executing, leaving the
system in a broken post-finish state. Wrap the runAll() invocation in a
try-catch block to isolate front-action failures while ensuring that reload,
completeActions, and close operations continue to execute regardless of whether
runAll throws an exception.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Handle frontend actions on task events
Implements ETASK-29
Dependencies
No new dependencies were introduced
Third party dependencies
No new dependencies were introduced
Blocking Pull requests
There are no dependencies on other PR
How Has Been This Tested?
manually
Test Configuration
Checklist:
Summary by CodeRabbit