Flow 中可能存在的错误
possible bug in Flow
Possible Bug:
当子 B 失败时,GenericWorkflowClientImpl 中的 handleStartChildWorkflowExecutionFailed 方法根据工作流 ID 作为键从 scheduledExternalWorkflows 映射中删除"OpenRequestInfo"。由于 5 个子工作流具有相同的工作流 ID。因此,一旦子 B 初始化失败,地图就变空了。因此,父工作流无法完成,因为 4 个子工作流请求永远无法在 handle* 方法中正确关闭。
第 335 行显示 handleStartChildWorkflowExecutionFailed 删除失败条目。
Update2: 问题仍未解决:(.
更新:可能是提交 0a183e02b29b06e9324b740af40daff9193c9290 修复了错误。请验证。
看起来 DecisionsHelper. It assumes that DecisionId 中的错误从未被重复使用,因为它从未从 decisions 地图中删除。 DecisionId 永远不会重复用于活动和 lambda,但正如您所发现的那样,它对于子工作流并不总是如此 :(。解决方法是不重复使用子工作流 ID。
在您的情况下,我看不出有什么理由尝试安排与父工作流具有相同 ID 的子工作流,因为父工作流具有有关子工作流状态的完整信息并且可以轻松避免它。顺便说一句,您是否考虑过在 CronWithRety 示例中将 CronInvocationSchedule 与 AsyncScheduledExecutor 一起使用?
但是,当父工作流的多个实例可以创建具有相同 ID 的子工作流时,此错误很严重。
@Override
protected ExternalTaskCancellationHandler doExecute(final ExternalTaskCompletionHandle handle) throws Throwable {
context.setCompletionHandle(handle);
String workflowId = attributes.getWorkflowId();
if (scheduledExternalWorkflows.containsKey(workflowId)) {
WorkflowExecution workflowExecution = new WorkflowExecution();
workflowExecution.setWorkflowId(workflowId);
WorkflowType workflowType = attributes.getWorkflowType();
long fakeEventId = -1;
handle.fail(new StartChildWorkflowFailedException(fakeEventId, workflowExecution, workflowType, StartChildWorkflowExecutionFailedCause.WORKFLOW_ALREADY_RUNNING.toString()) );
return new ChildWorkflowCancellationHandler(workflowId, handle);
}
decisions.startChildWorkflowExecution(attributes);
scheduledExternalWorkflows.put(workflowId, context);
return new ChildWorkflowCancellationHandler(workflowId, handle);
}
}
}
更新了此 class 中的第 162 行:
Possible Bug:
当子 B 失败时,GenericWorkflowClientImpl 中的 handleStartChildWorkflowExecutionFailed 方法根据工作流 ID 作为键从 scheduledExternalWorkflows 映射中删除"OpenRequestInfo"。由于 5 个子工作流具有相同的工作流 ID。因此,一旦子 B 初始化失败,地图就变空了。因此,父工作流无法完成,因为 4 个子工作流请求永远无法在 handle* 方法中正确关闭。
第 335 行显示 handleStartChildWorkflowExecutionFailed 删除失败条目。
Update2: 问题仍未解决:(.
更新:可能是提交 0a183e02b29b06e9324b740af40daff9193c9290 修复了错误。请验证。
看起来 DecisionsHelper. It assumes that DecisionId 中的错误从未被重复使用,因为它从未从 decisions 地图中删除。 DecisionId 永远不会重复用于活动和 lambda,但正如您所发现的那样,它对于子工作流并不总是如此 :(。解决方法是不重复使用子工作流 ID。
在您的情况下,我看不出有什么理由尝试安排与父工作流具有相同 ID 的子工作流,因为父工作流具有有关子工作流状态的完整信息并且可以轻松避免它。顺便说一句,您是否考虑过在 CronWithRety 示例中将 CronInvocationSchedule 与 AsyncScheduledExecutor 一起使用?
但是,当父工作流的多个实例可以创建具有相同 ID 的子工作流时,此错误很严重。
@Override
protected ExternalTaskCancellationHandler doExecute(final ExternalTaskCompletionHandle handle) throws Throwable {
context.setCompletionHandle(handle);
String workflowId = attributes.getWorkflowId();
if (scheduledExternalWorkflows.containsKey(workflowId)) {
WorkflowExecution workflowExecution = new WorkflowExecution();
workflowExecution.setWorkflowId(workflowId);
WorkflowType workflowType = attributes.getWorkflowType();
long fakeEventId = -1;
handle.fail(new StartChildWorkflowFailedException(fakeEventId, workflowExecution, workflowType, StartChildWorkflowExecutionFailedCause.WORKFLOW_ALREADY_RUNNING.toString()) );
return new ChildWorkflowCancellationHandler(workflowId, handle);
}
decisions.startChildWorkflowExecution(attributes);
scheduledExternalWorkflows.put(workflowId, context);
return new ChildWorkflowCancellationHandler(workflowId, handle);
}
}
}
更新了此 class 中的第 162 行: