本页面列出了 Workflows 的已知问题。
您还可以在公开问题跟踪器中检查现有问题或添加新问题。
将 for
放置在 try
的直接后面
将 for
直接放置在 try
后面会导致错误。例如,单个步骤可以直接放置在 try
后面,如下所示:
- try: try: call: sys.log args: data: works retry: ${http.default_retry}
不过,如果您将 for
放在 try
之后,该步骤将失败,并且您无法
部署工作流。例如:
- try: try: for: value: v range: [1,2] steps: - log: call: sys.log args: data: ${v} retry: ${http.default_retry}
错误消息如下所示:
Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)
解决方法是在 try
之后添加一个命名步骤。例如:
- try: try: steps: - loopStep: for: value: v range: [1,2] steps: - log: call: sys.log args: data: ${v} retry: ${http.default_retry}
事件大于参数大小上限
如果将 Workflows 作为 Eventarc 触发器的目的地,大于 Workflows 参数大小上限的事件将无法触发工作流执行。如需了解详情,请参阅配额和限制。
日志中出现 HTTP request lost
消息
执行调用 Cloud Build 的工作流时,工作流会失败,并且日志中会显示类似以下内容的 HTTP request lost
消息:
[1500] HTTP request lost INTERNAL MESSAGE: HTTP request lost ... CAUSED BY: RPC::UNREACHABLE: RPC connection timed out: FDD 20s, last read 2022-10-14 16:39:04 -0700 PDT
如果遇到此错误,请尝试修改工作流程,方法是执行 重试政策或通过明确的 异常处理。
调用日志记录和 accessString
方法以检索 Secret 数据
如果在使用 accessString
辅助方法检索 Secret 数据时,调用日志记录级别设置为 log-all-calls
,则系统不会隐去 Secret 值,而是将其以纯文本形式输出到 jsonPayload.succeeded.response
中的日志。
使用 Cloud Resource Manager 连接器时长时间运行的操作异常
Resource Manager 连接器方法 googleapis.cloudresourcemanager.v3.projects.patch
不会返回长时间运行的操作 (LRO) 名称。即使是成功的
请求,可能会引发类似于以下内容的异常:
exception: "{"message":"Long-running operation returned unexpected response.", "operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project", ... "tags":["ResponseTypeError"]}"
为避免 LRO 轮询错误,请将 skip_polling
连接器参数设置为 true
,以便在初始请求成功时,连接器调用调用是非阻塞的。成功的
请求会返回 "done":true
;否则,要捕获任何异常,请使用
try/except
结构。
有关详情,请参阅
连接器参考。
后续步骤
了解在排查问题时很有帮助的策略。