An orphaned action with the same order number as another action prevents a flow from loading - Known Error

An orphaned action with the same order number as another action prevents a flow from loading Description - Flow or OpsView doesn't load. Gets stuck while processing

- Console Error: uncaught at fetchFlowDetailsFromServerSaga TypeError: Cannot read property 'order' of undefined

Steps to Reproduce

1. Create a flow 2. Add an If 3. Inside the If, add two Logs 4. Navigate to sys_hub_action_instance and filter by your flow 5. Change the order of one of the Logs to "1" and its parent UI ID to gibberish, like "abc" 6. Re-open the flow

Expected: The flow loads Actual: The flow gets stuck at the processing modal

Workaround Cause "Orphaned" instances are component instances that contain a reference to a parent, but that parent is not found in the flow. As of now, we don't know exactly how these actions/subflows orphans are created, but we can use the existing STR to artificially create this scenario. These orphaned instances can prevent flows and execution details from opening. The user gets stuck while processing and a console log error that says "Console Error: uncaught at fetchFlowDetailsFromServerSaga TypeError: Cannot read property 'order' of undefined" can be seen. We recommend the following workaround if an upgrade is not yet possible.

Workaround First, we take the sys id of the flow that we can't open. Then we can use that sys id as the parameter for our fixOrphanedFlowInstances() function below.

function findAndRemoveOrphans(flowSysId) { var compGr = new GlideRecord('sys_hub_flow_component'); compGr.addQuery('flow', flowSysId); compGr.query(); var uiIdMap = {}; var currUiId = ''; var orphans = ["---- Deleted orphaned instances ----"]; while (compGr.next()) { currUiId = compGr.getValue('ui_id'); uiIdMap[currUiId] = currUiId; }

compGr.query(); while (compGr.next()) { currUiId = compGr.getValue('ui_id'); var parentUiId = compGr.getValue('parent_ui_id'); if (parentUiId && !uiIdMap[parentUiId]) { orphans.push('order: ' + compGr.getValue('order') + ', ui id: ' + currUiId); compGr.deleteRecord(); } }

return orphans; }

function fixOrphanedFlowInstances(flowSysId) { var mainFlowSysId = ''; var flowSnapshotGR = new GlideRecord('sys_hub_flow'); flowSnapshotGR.addQuery('sys_id', flowSysId); flowSnapshotGR.query(); if (flowSnapshotGR.next()) { mainFlowSysId = flowSnapshotGR.getValue('master_snapshot'); }

findAndRemoveOrphans(flowSysId); var orphans = findAndRemoveOrphans(mainFlowSysId);

gs.print(orphans.join('\n')); }

fixOrphanedFlowInstances( ); We run this script in the background scripts on the platform. We should see a result screen like the following image. We should see at the end of the logging message that orphaned instances have been deleted. If there are no orphaned instances deleted, then it's possible that the issue lies in a subflow within that flow. If that's the case, then we need to run this script for any subflows within the flow until we find the orphaned instances. If there are no orphaned instances, then the issue could be due to PRB1488650.

If there are orphaned instances and they are deleted, then we should try to open the flow and see if the issue is resolved. If we're trying to open execution details, unfortunately, previous executions that contain the orphaned instances will still be broken, but after republishing the flow, future execution details will be viewable.