Flow Designer visibility failure

[Ricardo Fonseca]

Hello guys.
After upgrading our instance from the Tokyo version to Vancouver, we noticed an impact on the Flow Designer visualization:

In summary, after executing the flow successfully, Servicenow changes the name of the subflow to "payload" (I don't understand where this name comes from, as the subflow has a completely different name) and it is not possible to view its details, the subflow is stuck and the actions that were performed do not appear.

I added 3 evidence that explain the problem.

Thanks a lot for the help,

Best Regards,

[Sohail Khilji]

Hi @Ricardo Fonseca ,

Hard to find root cause, this is strange behavior... I believe you need to look for KBs that can help you with this exact issue. If not create a support case... 

I hope this helps 

[Ricardo Fonseca]

Hi @Sohail Khilji , thanks a lot for reply!

Some additional information that can support the analysis:

The Flow was failing to run, with the error "Error while fetching process plan for the subflow: 'sys_id' ".

In addition, it was possible to view the error below in detail in the Flow Engine Context:

Flow Designer: Flow is empty. Unable to compile the flow: com.glide.flow.exceptions.FlowCompilerException: Flow is empty. Unable to compile the flow: com.glide.flow.compiler.FlowGlideCompiler.compile(FlowGlideCompiler.java:95)
com.glide.flow.compiler.v2.EngineVersionAwareFlowCompiler.compile(EngineVersionAwareFlowCompiler.java:52)
com.glide.flow.providers.FlowGlideProvider.getFlowPlan(FlowGlideProvider.java:1827)
com.glide.flow_trigger.engine.FlowPlanRetriever.recompileAndCacheProcessPlan(FlowPlanRetriever.java:272)
com.glide.flow_trigger.engine.FlowPlanRetriever.retrieve(FlowPlanRetriever.java:218)
com.glide.flow_trigger.engine.FlowPlanRetriever.retrieve(FlowPlanRetriever.java:173)
com.snc.process_flow.engine.subflow.StartFlowOperation.getSubflowPlan(StartFlowOperation.java:112)
com.snc.process_flow.engine.subflow.StartFlowOperation.getSubflowPlanById(StartFlowOperation.java:134)
com.snc.process_flow.engine.subflow.StartFlowOperation.getSubflowPlan(StartFlowOperation.java:213)
com.snc.process_flow.engine.subflow.StartFlowOperation.run(StartFlowOperation.java:280)
com.snc.process_flow.engine.Operation.execute(Operation.java:207)
com.snc.process_flow.engine.restricted_caller_access.ExecuteWithCallerAccessTracking.executeWithMetaStack(ExecuteWithCallerAccessTracking.java:21)
com.snc.process_flow.engine.ProcessEngine.executeOps(ProcessEngine.java:618)
com.snc.process_flow.engine.ProcessEngine.runInternal(ProcessEngine.java:515)
com.snc.process_flow.engine.ProcessEngine.run(ProcessEngine.java:502)
com.snc.process_flow.engine.ProcessAutomation.run(ProcessAutomation.java:101)
com.snc.process_flow.engine.GlideProcessAutomation.runSync(GlideProcessAutomation.java:184)
com.snc.process_flow.engine.GlideProcessAutomation.runWithDomain(GlideProcessAutomation.java:343)
com.snc.process_flow.engine.GlideProcessAutomation.lambda$runAsUserSync$1(GlideProcessAutomation.java:310)
com.snc.process_flow.engine.PFSessionClone.run(PFSessionClone.java:71)
com.snc.process_flow.engine.GlidePFSession.runPlanAsUserSession(GlidePFSession.java:42)
com.snc.process_flow.engine.GlideProcessAutomation.runAsUserSync(GlideProcessAutomation.java:308)
com.snc.process_flow.engine.GlideProcessAutomation.messageFlow(GlideProcessAutomation.java:394)
com.snc.process_flow.engine.GlideProcessAutomation.messageFlow(GlideProcessAutomation.java:373)
com.snc.process_flow.engine.ProcessHubEventHandler.doSendMessage(ProcessHubEventHandler.java:479)
com.snc.process_flow.engine.ProcessHubEventHandler.process(ProcessHubEventHandler.java:129)
com.snc.process_flow.engine.ProcessHubEventHandler.process(ProcessHubEventHandler.java:97)
com.snc.process_flow.engine.FlowEventManager.processEvents(FlowEventManager.java:168)
com.glide.job.EventHandlerJob.execute(EventHandlerJob.java:50)
com.glide.schedule.JobExecutor.lambda$executeJob$0(JobExecutor.java:169)
com.glide.schedule.JobExecutor.executeJob(JobExecutor.java:172)
com.glide.schedule.JobExecutor.execute(JobExecutor.java:155)
com.glide.schedule.JobExecutor.execute(JobExecutor.java:149)
com.glide.schedule_v2.SchedulerWorkerThread.executeJob(SchedulerWorkerThread.java:449)
com.glide.schedule_v2.SchedulerWorkerThread.lambda$process$1(SchedulerWorkerThread.java:318)
com.glide.worker.TransactionalWorkerThread.executeInTransaction(TransactionalWorkerThread.java:35)
com.glide.schedule_v2.SchedulerWorkerThread.process(SchedulerWorkerThread.java:318)
com.glide.schedule_v2.SchedulerWorkerThread.run(SchedulerWorkerThread.java:118)

After that, we added the subflow from our DEV environment to an update set and updated it in the QA environment (which is where the problem is occurring).

[Sohail Khilji]

Did you try to roll back that particular update set on your QA to see if everything is smooth ?

[Ricardo Fonseca]

Yes, we backed out the update set, but the subflow remained with the strange name "payload" and it was not possible to see the actions that had been executed. ☹️