[MGNLWORKFLOW-116] Fix exception handling in case or problems in workflows Created: 16/Aug/13  Updated: 02/Oct/13  Resolved: 01/Oct/13

Status: Closed
Project: Magnolia Workflow Module
Component/s: None
Affects Version/s: 5.0
Fix Version/s: 5.1

Type: Improvement Priority: Critical
Reporter: Daniel Lipp Assignee: Espen Jervidalo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-5348 Re-introduce setting command executio... Closed
duplicate
duplicates MGNLWORKFLOW-133 workflow doesn't detect missing publi... Closed
supersession
supersedes MGNLWORKFLOW-133 workflow doesn't detect missing publi... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)

 Description   

The Approve & publish (and the reject) action don't properly react on failures. Right now they'll always result in the corresponding jbpm-workItem (not the magnolia Message) being removed.

Sample scenario:

  • publish any page in a setup without proper public instance subscribed
  • go to the pulse, "Approve & publish" it
  • you'll get an activation exception
  • try again to "Approve & publish"
    -> system tells u that this workItem has been treated in the meanwhile
    -> there's no way to e.g. register a proper subscriber and retry


 Comments   
Comment by Daniel Lipp [ 16/Aug/13 ]

Right now we react as follows in the case of exceptions (e.g. no valid subscriber, try to "Approve & publish"):

  • user gets a red banner for the error (correct)
  • user gets a info notification that the workflow was processed (wrong)
  • jbpm workItem is removed (wrong)

This has to be enhanced.

Comment by Daniel Lipp [ 16/Aug/13 ]

Hint: CommandWorkItemHandler#executeWorkItem(WorkItem, WorkItemManager) currently just calls onError which itself sends a local message -> hence later CompleteTaskAction assumes everything is fine and opens a notification message via the Shell.

Changing CommandWorkItemHandler#executeWorkItem(WorkItem, WorkItemManager) e.g. like:

try {
    commandsManager.executeCommand(commandName, parameters);
} catch (Exception e) {
    throw new RuntimeException("Exception trying to execute command " + commandName, e);
}

results in just an error message and now wrong workflow was processed message. Also the workItem will not be removed.
Unfortunately - on a next try to "Approve & publish" this workItem will claimed to be properly treated: no exception, but just a success message and it'll be removed.

Generated at Mon Feb 12 10:06:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.