Workflows의 알려진 문제

이 페이지에는 Workflows에서 알려진 문제가 나와 있습니다.

공개 Issue Tracker에서도 기존 문제를 확인하거나 새로운 문제를 개설할 수 있습니다.

try 바로 뒤에 for 배치

try 바로 뒤에 for를 배치하면 오류가 발생합니다. 예를 들어 다음과 같이 try 바로 뒤에 단일 단계를 배치할 수 있습니다.

- try:
    try:
      call: sys.log
      args:
        data: works
    retry: ${http.default_retry}

그러나 try 뒤에 for를 배치하면 단계가 실패하고 워크플로를 배포할 수 없습니다. 예를 들면 다음과 같습니다.

- 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 메서드를 호출하여 보안 비밀 데이터 가져오기

accessString 도우미 메서드를 사용해 보안 비밀 데이터를 가져올 때 호출 로깅 수준이 log-all-calls로 설정되어 있으면 보안 비밀 값이 수정되지 않고 로그의 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 구조를 사용합니다. 자세한 내용은 커넥터 참조를 확인하세요.

Google Kubernetes Engine (GKE)에 대한 HTTP 요청

모든 GKE 클러스터에는 Kubernetes API 요청을 처리하는 컨트롤 플레인이 있습니다. 컨트롤 플레인에는 클러스터 액세스를 위한 두 가지 종류의 엔드포인트가 있습니다. DNS 기반 엔드포인트와 IP 기반 엔드포인트입니다. 자세한 내용은 제어 영역 액세스를 참고하세요.

Workflows는 더 이상 GKE 클러스터 컨트롤 플레인의 IP 기반 엔드포인트에 대한 HTTP 요청을 지원하지 않습니다. 이번 지원 중단의 범위와 영향에 대한 자세한 내용은 서비스 공지사항을 참고하세요.

워크플로가 예상대로 작동하려면 DNS 기반 엔드포인트에 액세스해야 합니다. DNS 기반 엔드포인트에 액세스하려면 워크플로에서 Kubernetes API 커넥터를 사용하는 것이 좋습니다. 자세한 내용은 커넥터를 사용하여 Kubernetes API 객체 액세스를 참고하세요.

다음 단계

문제 해결 시 유용한 전략 알아보기