Jump to content

Recommended Posts

Posted

Hi

I have noticed a few times in the last week where a ticket will give an error and the suspended process has stopped at an Lock/Unlock actions node,

If I Click on "restart the last step" it does restart.  This has happened on a few different tickets and catalog items and most work fine.  All the business processes have the same "Show Resolved Action"

Any suggestions? 

Helen

image.thumb.png.a62231ecd4f92922431ee541d2102759.png image.png.18eb21a4c7698918974f4e5c16b67b62.png

Posted

I am having the same issue on our workflows, and not only on lock/unlock actions, but also for suspend actions.

The error you have shown is exactly the same as mine, and it started to happen after the new patch. If I restart the workflow manually, it then works.

Support was unable to pinpoint the exact issue, does anyone have a solution for this?

Thanks.

  • Like 1
Posted

We are also experiencing this issue with a suspend node in one of our workflows.  I am awaiting updates from support via the ticket I have raised.

  • Like 1
Posted
19 hours ago, Jacopo Carraro said:

does anyone have a solution for this?

Currently the only available workaround is to restart the failed Workflow.
We appreciate this is not ideal as it requires manual intervention and only a select few Users will have that capability, which is why we are investigating this as a priority.

We will post back here when we have further information so that anyone without a Support Incident raised can see the progress.

  • Like 3
  • Thanks 1
Posted

For some reason in the past few days processes that have worked perfectly for the past year have started throwing this error, along with suspend and wait for attachments also. Has anyone else noticed this behaviour? ..the weird thing is I don't even have to fix them, just resume the process and it all goes green

image.png.2f5dbeefc53f99a653772184e5f38447.png

  • Steve Giller changed the title to Error in Workflow on Unlock actions
  • 2 weeks later...
Posted

I'm seeing this as well; in addition, autotasks which update a suspend condition are now no longer having an effect on the workflow; I have to manually resume them after the autotask has updated the condition.

Posted

We've started seeing this now also. Hoping for a patch on this or faster-than-usual release. This is similar to the issue with the Suspend for Asset. These two issues are starting to create the perception in the user base that the product is getting unstable.

image.png.8c559116bd0d7c186362ea85f22f73d7.png

  • Like 2
Posted
On 23/04/2024 at 10:39, Mike Hillman said:

We're seeing this too, although not very often as yet - last occurred at the end of last week

I've now had several other instances of the workflow crashing on Lock Actions over yesterday and today

Posted

Hi 

We are still being affected by this and it is affecting the analysts closure figures as tickets are shown as breached if we don't get to restart the process in time

Could we please get an update on when this might be fixed?

As @Berto2002 commented it is also having an negative impact on our user base

On 24/04/2024 at 14:17, Berto2002 said:

These two issues are starting to create the perception in the user base that the product is getting unstable.

Thanks 

Helen 

  • 2 weeks later...
Posted

Just had another failure on an Unlock action, trying to unlock the "Resolve" tab:

Status : Failed
Last Updated On : 10-05-2024 15:06:52
Xmlmc method invocation failed for BPM invocation node '2432dabc-0f53-1070-4eb6-518b889d6539/flowcode-4d3507ed': <methodCallResult status="fail"> <state> <code>0207</code> <service>apps</service> <operation>lockActions</operation> <error>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js(189): error X1001: Uncaught EspMethodCall::invoke: Operation[data::entityUpdateRecord] Superfluous entity record update detected for &apos;Requests&apos;. The primary record was updated but no data changes were applied.</error> <flowcodeError> <where>Execute</where> <filename>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js</filename> <lineNumber>189</lineNumber> <columnPos>20</columnPos> <message>Uncaught EspMethodCall::invoke: Operation[data::entityUpdateRecord] Superfluous entity record update detected for &apos;Requests&apos;. The primary record was updated but no data changes were applied.</message> <errorCode>1001</errorCode> <stackTrace>invoke at /apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js(189:21)</stackTrace> <stackTrace>entityUpdateRecord at /apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js(614:54)</stackTrace> <stackTrace>bpm_lockActions at /apps/com.hornbill.servicemanager/entities/Requests/fc_modules/requests_helper.js(11419:24)</stackTrace> <stackTrace>at /apps/com.hornbill.servicemanager/entities/Requests/fc_bpm/lockActions.js(6:30)</stackTrace> </flowcodeError> </state> </methodCallResult>

Its not happening consistently, but enough to cause complaints from our users.

Posted

Ours this morning was "Xmlmc method invocation failed for BPM invocation node 'stage-ad749c2a/flowcode-1546d2ee': <methodCallResult status="fail"> <state> <code>0207</code> <service>apps</service> <operation>suspendLinkedAssets</operation> <error>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js(189): err..." on the wait for asset node again

Posted

We've been getting this on one particular suspend node intermittently as well. I'm able to restart the workflow each time and they work okay after.

Posted

And we get it just after the suspend for asset to be attached also. This is a known system-wide issue Hornbill seem to be struggling to fix and is affecting many customers.

  • Like 1
Posted

This was previously happening to us intermittently however we are now seeing this happen daily as of the last 3 days.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...