Nesta página, listamos os problemas conhecidos do Workflows.
Você também pode verificar problemas existentes ou abrir novos nos issue trackers públicos.
Posição de for
diretamente após try
Colocar for
logo após try
causa um erro. Por exemplo, uma única etapa
pode ser colocado logo após try
, desta forma:
- try: try: call: sys.log args: data: works retry: ${http.default_retry}
No entanto, se você posicionar for
depois da try
, a etapa falhará e não será possível
implantar o fluxo de trabalho. Exemplo:
- try: try: for: value: v range: [1,2] steps: - log: call: sys.log args: data: ${v} retry: ${http.default_retry}
A mensagem de erro é a seguinte:
Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)
A solução é adicionar uma etapa nomeada após a try
. Exemplo:
- try: try: steps: - loopStep: for: value: v range: [1,2] steps: - log: call: sys.log args: data: ${v} retry: ${http.default_retry}
Eventos maiores que o tamanho máximo dos argumentos
Se você estiver usando o Workflows como destino para um Gatilho do Eventarc, eventos maiores que o máximo O tamanho dos argumentos de Workflows não vai acionar o fluxo de trabalho execuções. Para mais informações, consulte Cotas e limites.
Mensagem HTTP request lost
nos registros
Ao executar um fluxo de trabalho que chama o Cloud Build, ele falha
há uma mensagem HTTP request lost
nos registros semelhante à seguinte:
[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
Se você encontrar esse erro, tente modificar seu fluxo de trabalho implementando uma política de repetição ou por meio de políticas gerenciamento de exceções.
Registro de chamadas e método accessString
para recuperar dados do secret
Se o
nível de registro de chamadas estiver definido como
log-all-calls
ao
usar o método auxiliar accessString
para recuperar dados secretos,
o valor secreto não será ocultado e será impresso em texto simples nos registros em
jsonPayload.succeeded.response
.
Exceção de operação de longa duração ao usar o conector do Cloud Resource Manager
O método do conector do Resource Manager,
googleapis.cloudresourcemanager.v3.projects.patch
,
não retorna um nome de operação de longa duração (LRO, na sigla em inglês). Mesmo para um site de sucesso
solicitação, uma exceção semelhante à seguinte poderá ser gerada:
exception: "{"message":"Long-running operation returned unexpected response.", "operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project", ... "tags":["ResponseTypeError"]}"
Para evitar um erro de pesquisa de LRO,
defina o parâmetro do conector skip_polling
como true
para que a chamada de invocação
do conector não seja bloqueada se a solicitação inicial for bem-sucedida. Um bem-sucedido
request retorna "done":true
; caso contrário, para capturar exceções, use um
estrutura try/except
.
Para mais informações, consulte a
Referência de conectores.
A seguir
Conheça estratégias úteis para resolver problemas.