apache/beam · warning

Waiting for timeout check to complete

Error message

Waiting for timeout check to complete

What it means

On teardown, WriteBatches cancels its scheduled expiration check and then waits for any in-flight check future to finish before writing remaining batches (to avoid writing to locked/expired batches concurrently). If the check doesn't finish within EXPIRATION_CHECK_TIMEOUT_SECS, it logs this warning and waits again.

Source

Thrown at sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/sqs/SqsIO.java:669

      /** Submit entries of a {@link Batch} to the async write handler. */
      private void submitEntries(Batch batch, boolean throwFailures) {
        try {
          handler.batchWrite(batch.queue, batch.getAndClose(), throwFailures);
        } catch (RuntimeException e) {
          throw e;
        } catch (Throwable e) {
          throw new RuntimeException(e);
        }
      }

      public void finishBundle() throws Throwable {
        if (expirationCheck != null) {
          expirationCheck.cancel(false);
          while (true) {
            try {
              expirationCheck.get(EXPIRATION_CHECK_TIMEOUT_SECS, TimeUnit.SECONDS);
            } catch (TimeoutException e) {
              LOG.warn("Waiting for timeout check to complete");
            } catch (CancellationException e) {
              break; // scheduled checks completed after cancellation
            }
          }
        }
        // safe to write remaining batches without risking to encounter locked ones
        checkState(batches.submitAll());
        handler.waitForCompletion();
      }

      @Override
      public void close() throws Exception {
        sqs.close();
        if (scheduler != null) {
          scheduler.shutdown();
        }
      }

View on GitHub (pinned to 12126d8942)

Solutions

1. No user fix required — the loop keeps waiting until the check completes or is cancelled; teardown continues afterwards
2. Reduce SQS client request timeouts so a stuck check fails fast instead of hanging
3. Check for SQS throttling/network problems at shutdown time
4. Ensure the writer isn't starved of threads by other concurrent sinks sharing an executor

// wait pattern matching the library's
while (true) {
  try { future.get(timeout, TimeUnit.SECONDS); break; }
  catch (TimeoutException e) { LOG.warn("still waiting for check"); }
  catch (CancellationException e) { break; }
}

When it happens

Trigger: Pipeline teardown while a scheduled SQS message-expiration check task is still executing; repeated get() timeouts mean the check task is stuck (e.g. blocked on an SQS API call) for longer than EXPIRATION_CHECK_TIMEOUT_SECS each attempt.

Common situations: SQS endpoint slowness or throttling at shutdown; very large batch pending while the check loop runs; executor starvation from other SQS writer tasks.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• Executor service is taking long time to shutdown, will retry
• Timed out waiting for service after ${timeoutMs}ms.
• Timeout waiting for Python service startup after ${elapsed}
• to(queueUrl) or to(dynamicDestination) is required
• Failed to delete pendingDeletes.size() messages after retrie

AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/328c8a433db87a32. Report an issue: GitHub.