[MGNLWORKFLOW-335] Workflow "Publish" broken due to ScheduleTaskWorkItemHandler Created: 11/Jul/16  Updated: 15/Jul/16  Resolved: 14/Jul/16

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

Type: Bug Priority: Critical
Reporter: Richard Unger Assignee: Unassigned
Resolution: Not an issue Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

LFRZ


Issue Links:
Relates
relates to MGNLWORKFLOW-290 Use scheduled task instead of jBPM timer Closed
duplicate
duplicates MGNLWORKFLOW-329 publish workflow fails when configured 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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

5.4.? introduced the following bug compared to 5.3:

When using the "Publication" workflow (publication/Publication.bpmn2) since upgrading to Magnolia 5.4, the attempt to launch the workflow fails with an Exception.

The problem seems to be with the new class ScheduleTaskWorkItemHandler which in line 42 retrieves a task ID, and in line 43 attempts to load a HumanTask using this id.
The problem is that in the case of the Publication workflow there is no human task (it's just a timer for delayed publication) and therefore the ID is null, and line 43 fails due to NPE.

info.magnolia.module.workflow.api.WorkflowException: Error starting workflow.
        at info.magnolia.module.workflow.jbpm.JbpmWorkflowManager.launch(JbpmWorkflowManager.java:81)
        at info.magnolia.module.workflow.commands.LaunchWorkflowCommand.execute(LaunchWorkflowCommand.java:72)
        at info.magnolia.commands.MgnlCommand.executeSynchronized(MgnlCommand.java:80)
        at info.magnolia.commands.MgnlCommand.execute(MgnlCommand.java:69)
        at info.magnolia.commands.chain.ChainBase.execute(ChainBase.java:101)
        at info.magnolia.commands.DelegateCommand.execute(DelegateCommand.java:66)
        at info.magnolia.commands.CommandsManager.executeCommand(CommandsManager.java:256)
        at info.magnolia.commands.CommandsManager.executeCommand(CommandsManager.java:244)
        at info.magnolia.ui.framework.action.AbstractCommandAction.executeOnItem(AbstractCommandAction.java:202)
        at info.magnolia.ui.framework.action.AbstractMultiItemAction.execute(AbstractMultiItemAction.java:107)
        at info.magnolia.ui.api.action.AbstractActionExecutor.execute(AbstractActionExecutor.java:62)
        at info.magnolia.ui.dialog.BaseDialogPresenter.executeAction(BaseDialogPresenter.java:211)
        at info.magnolia.ui.dialog.BaseDialogPresenter.onActionFired(BaseDialogPresenter.java:201)
        at info.magnolia.ui.dialog.actionarea.renderer.DefaultEditorActionRenderer$DefaultActionView$1.buttonClick(DefaultEditorActionRenderer.java:75)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:508)
        at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:198)
        at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:161)
        at com.vaadin.server.AbstractClientConnector.fireEvent(AbstractClientConnector.java:977)
        at com.vaadin.ui.Button.fireClick(Button.java:393)
        at com.vaadin.ui.Button$1.click(Button.java:61)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
...

Caused by: org.jbpm.workflow.instance.WorkflowRuntimeException: [info.magnolia.workflow.Publication:1,467,902,295,756 - Schedule Publication:6] -- Impossible to get the objec
t with uuid : null
        at org.jbpm.workflow.instance.node.WorkItemNodeInstance.internalTrigger(WorkItemNodeInstance.java:144)
        at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:171)
        at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:364)
        at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerConnection(NodeInstanceImpl.java:379)
        at org.jbpm.workflow.instance.node.SplitInstance.executeStrategy(SplitInstance.java:117)
        at org.jbpm.workflow.instance.node.SplitInstance.internalTrigger(SplitInstance.java:63)
        at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:171)
        at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:364)
        at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:323)
        at org.jbpm.workflow.instance.node.StartNodeInstance.triggerCompleted(StartNodeInstance.java:73)
        at org.jbpm.workflow.instance.node.StartNodeInstance.internalTrigger(StartNodeInstance.java:44)
        at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:171)
        at org.jbpm.ruleflow.instance.RuleFlowProcessInstance.internalStart(RuleFlowProcessInstance.java:35)
        at org.jbpm.process.instance.impl.ProcessInstanceImpl.start(ProcessInstanceImpl.java:236)
        at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.start(WorkflowProcessInstanceImpl.java:389)
        at org.jbpm.process.instance.ProcessRuntimeImpl.startProcessInstance(ProcessRuntimeImpl.java:195)
        at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:177)
        at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:169)
        at org.drools.core.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:1901)
        at org.drools.core.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:122)
        at org.drools.core.command.runtime.process.StartProcessCommand.execute(StartProcessCommand.java:40)
        at org.drools.core.command.impl.DefaultCommandService.execute(DefaultCommandService.java:36)
        at org.drools.core.command.impl.AbstractInterceptor.executeNext(AbstractInterceptor.java:41)
        at org.drools.persistence.SimpleSessionCommandService$TransactionInterceptor.execute(SimpleSessionCommandService.java:334)
        at org.drools.core.command.impl.AbstractInterceptor.executeNext(AbstractInterceptor.java:41)
        at org.drools.persistence.jcr.JcrPersistInterceptor.execute(JcrPersistInterceptor.java:42)
        at org.drools.core.command.impl.AbstractInterceptor.executeNext(AbstractInterceptor.java:41)
        at org.jbpm.persistence.JcrPersistProcessInterceptor.execute(JcrPersistProcessInterceptor.java:55)
        at org.drools.persistence.SimpleSessionCommandService.execute(SimpleSessionCommandService.java:251)
        at org.drools.core.command.impl.CommandBasedStatefulKnowledgeSession.startProcess(CommandBasedStatefulKnowledgeSession.java:242)
        at info.magnolia.module.workflow.jbpm.JbpmWorkflowManager.launch(JbpmWorkflowManager.java:74)
        ... 142 more

Caused by: org.apache.jackrabbit.ocm.exception.RepositoryException: Impossible to get the object with uuid : null
        at org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.getObjectByUuid(ObjectContentManagerImpl.java:281)
        at info.magnolia.task.persistence.TasksStoreImpl$3.exec(TasksStoreImpl.java:170)
        at info.magnolia.task.persistence.TasksStoreImpl$3.exec(TasksStoreImpl.java:163)
        at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:392)
        at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:377)
        at info.magnolia.task.persistence.TasksStoreImpl.getTaskById(TasksStoreImpl.java:163)
        at info.magnolia.task.DefaultTasksManager.getTaskById(DefaultTasksManager.java:155)
        at info.magnolia.module.workflow.jbpm.workitem.handler.ScheduleTaskWorkItemHandler.executeWorkItem(ScheduleTaskWorkItemHandler.java:43)
        at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper$1.exec(WorkItemHandlerSystemContextWrapper.java:37)
        at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper$1.exec(WorkItemHandlerSystemContextWrapper.java:33)
        at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:392)
        at info.magnolia.context.MgnlContext.doInSystemContext(MgnlContext.java:377)
        at info.magnolia.module.workflow.jbpm.persistence.WorkItemHandlerSystemContextWrapper.executeWorkItem(WorkItemHandlerSystemContextWrapper.java:33)
        at org.drools.persistence.jcr.processinstance.JcrWorkItemManager.internalExecuteWorkItem(JcrWorkItemManager.java:76)
        at org.jbpm.workflow.instance.node.WorkItemNodeInstance.internalTrigger(WorkItemNodeInstance.java:133)
        ... 172 more
Caused by: javax.jcr.RepositoryException: invalid identifier: null
        at org.apache.jackrabbit.core.SessionImpl.getNodeByIdentifier(SessionImpl.java:1100)
        at info.magnolia.jcr.wrapper.DelegateSessionWrapper.getNodeByIdentifier(DelegateSessionWrapper.java:182)
        at info.magnolia.jcr.wrapper.DelegateSessionWrapper.getNodeByIdentifier(DelegateSessionWrapper.java:182)
        at info.magnolia.jcr.decoration.ContentDecoratorSessionWrapper.getNodeByIdentifier(ContentDecoratorSessionWrapper.java:129)
        at info.magnolia.jcr.wrapper.DelegateSessionWrapper.getNodeByIdentifier(DelegateSessionWrapper.java:182)
        at info.magnolia.jcr.wrapper.NodeWrappingDelegateSessionWrapper.getNodeByIdentifier(NodeWrappingDelegateSessionWrapper.java:58)
        at info.magnolia.jcr.wrapper.DelegateSessionWrapper.getNodeByIdentifier(DelegateSessionWrapper.java:182)
        at info.magnolia.jcr.decoration.ContentDecoratorSessionWrapper.getNodeByIdentifier(ContentDecoratorSessionWrapper.java:129)
        at info.magnolia.jcr.wrapper.DelegateSessionWrapper.getNodeByIdentifier(DelegateSessionWrapper.java:182)
        at info.magnolia.jcr.decoration.ContentDecoratorSessionWrapper.getNodeByIdentifier(ContentDecoratorSessionWrapper.java:129)
        at org.apache.jackrabbit.ocm.manager.impl.ObjectContentManagerImpl.getObjectByUuid(ObjectContentManagerImpl.java:275)
        ... 186 more
Caused by: java.lang.IllegalArgumentException: NodeId.valueOf(null)
        at org.apache.jackrabbit.core.id.NodeId.valueOf(NodeId.java:54)
        at org.apache.jackrabbit.core.SessionImpl.getNodeByIdentifier(SessionImpl.java:1098)
        ... 196 more

Related problem:
Note also that the error feedback in this case is insufficient. There is only an ugly warning box, with untranslated i18n label, that disappears before you can read it. There is no entry in pulse, and no way to know what happened without going to the server logs.



 Comments   
Comment by Richard Unger [ 12/Jul/16 ]

Before fixing the error, please take a look at the current error handling in this case. As it is at the moment, the error handling / error display to the user definately needs improvement. Thanks!

Comment by Espen Jervidalo [ 14/Jul/16 ]

The sub-process Publication.bpmn2 is not meant as a stand-alone process for circumventing the review-process in publication. In newer versions of that sub-process we moved away from the jbpm-timer instance, as it meant losing control of the execution and burying the publication deep inside the jbpm engine with practically no way to reveal those "scheduled publications".
In newer versions of the sub-process the ScheduleTaskWorkItemHandler will take care of marking the task as scheduled, with an according flag on the task-object in JCR. As a consequence the sub-process now has a dependency to e.g. the task-id which might not have been the case in earlier versions.

While we have split out sub-processes from the publication process, they are not supposed to be treated as stand-alone processes as there will always be a parameter-wise dependency between the parent-process and its sub-processes. Hence closing this issue.

Comment by Richard Unger [ 14/Jul/16 ]

Sorry, but this isn't good enough.

Firstly, you completely ignore the part of the ticket related to the error message. At the moment, the error message is clearly insufficient. It cannot be read (UI display problems), disappears much too quickly, and even if you manage to read the text it is a generic exception message string that does not help the user understand what the problem is. This isn't sufficient for an end-user error message.

Secondly, solving this issue is necessary to solve our support ticket: https://jira.magnolia-cms.com/browse/SUPPORT-6328
So you can't just close this with no solution. Prior to magnolia 5.4 we had a working out-of-the-box solution for timed publishing with no review step. 5.4 broke that solution, and we want a fix so that our users can do scheduled publications without the review step.

Comment by Richard Gange [ 14/Jul/16 ]

Hi Richard-

Prior to magnolia 5.4 we had a working out-of-the-box solution for timed publishing with no review step.

Please understand that prior to 5.4 we had this issue to deal with MGNLWORKFLOW-331. So to be completely transparent the old module was broke. If you had any scheduled publications they would be lost upon restart. So configuring the publish workflow was not a working solution.

5.4 broke that solution, and we want a fix so that our users can do scheduled publications without the review step.

This isn't completely accurate. The old module was broke because it was using a "timer" and not a "scheduler". We did not realize the consequence of that until later. If you want to be able to schedule publications but not have the review step then you should not use workflow but instead use tasks and scheduling. The downside of that is there is no way to handle a failed publication.

Or you can use the auto-approver module I provided on SUPPORT-6328.

HTH
Rich

Comment by Espen Jervidalo [ 15/Jul/16 ]

Hi Richard

Already in Magnolia 5.3 we introduced the tasks in combination with the publication-workflow. The scheduling was using the jbpm-timer, but the error-handling was already relying on tasks. In case the publication was failing, it would get the belonging task and set the status to failed, which allows to re-try the publication. Without the associated task, there is no proper error-handling in place and one would need to come up with a custom solution. I don't see how that could have been working with your setup in earlier versions either.
Depending on where the process fails, we have implemented proper error-handling where it makes sense. But especially when it comes to customised solution there is no defined error-path we can cover, please also refer to the documentation where this topic is covered:
https://documentation.magnolia-cms.com/display/DOCS/Custom+tasks#Customtasks-Errorhandling

If you need some help implementing the solution you had in place before on a newer Magnolia version, I would be glad to give you some hints, but I don't see any solution that would make it into the product. We are discussing the topic internally for future versions, but it's not possible to provide something in a minor version.

I hope you see my point and I'm sorry for the struggle.

Cheers,
Espen

Comment by Richard Unger [ 15/Jul/16 ]

Thanks for the more detailed feedback, also in the support ticket. I now understand much better what is going on.
I've added a comment on how we will proceed on our side in the support ticket, and understand why this one is closed.

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