Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Temporal SDK gRPC calls fail with DEADLINE_EXCEEDED after node restart (GraalVM / K8s)

オープン
  • 何か問題がありますか？
#2,840 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
静か
技術スタック
grpc, java, kubernetes, spring-boot
領域
backend, cloud, distributed-systems, networking

調査の方向性

リンクされている temporal-graalvm-k8s デモ、その Helm インストール、および起動時の listNamespaces 呼び出しから始めます。Kubernetes ノードを drain または再起動して失敗を再現し、報告されている DEADLINE_EXCEEDED ログを使って、native-image の動作を JVM および Kubernetes 外での実行と比較します。Temporal クラスターが正常な状態で、アプリケーションが再接続し、listNamespaces が速やかに成功すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

When a Spring Boot application using the Temporal Java SDK is compiled as a GraalVM native image and deployed in Kubernetes, the application fails to communicate with Temporal after node restarts or pod rescheduling.

The same application works correctly:

  • ✅ On JVM (non-native)
  • ✅ In Docker outside Kubernetes
  • ❌ Fails in Kubernetes when running as GraalVM native image

This suggests a compatibility issue between Temporal Java SDK and GraalVM native runtime, potentially related to:

  • gRPC channel lifecycle
  • DNS resolution / service discovery
  • resource or reflection configuration
  • connection reuse after pod rescheduling
Steps to Reproduce
  1. Install Temporal using official Helm chart - https://github.com/temporalio/helm-charts
  2. Deploy demo application - https://github.com/olegdibrov/temporal-graalvm-k8s
    Install the app:
    helm install control {path/to/chart}

Application logic (executed on startup):

List<DescribeNamespaceResponse> namespaces = workflowClient
    .getWorkflowServiceStubs()
    .blockingStub()
    .listNamespaces(ListNamespacesRequest.newBuilder().build())
    .getNamespacesList();
log.info("Found {} namespaces", namespaces.size());
  1. Restart Kubernetes node OR drain node:
    kubectl drain <node> --ignore-daemonsets
    Observe application startup behavior
Actual Behavior

Application fails to start for 10–30 minutes

Repeated errors:
io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: Deadline CallOptions was exceeded after 9.999s
Temporal cluster is healthy (all pods ready)
Eventually, the application may recover without restart

Expected Behavior
  • Application should reconnect to Temporal immediately after pod restart
  • listNamespaces should succeed consistently
  • No prolonged unavailability if Temporal cluster is healthy
Important Observations
  • Issue only occurs in GraalVM native image
  • Does NOT reproduce on JVM
  • Does NOT reproduce outside Kubernetes
  • Temporal services are reachable and healthy during failure window

Delay (~10–30 minutes) suggests:

  • stale DNS cache
  • broken gRPC channel reuse
  • or native-image-related networking issue
Environment
  • Temporal SDK: 1.33.0
  • GraalVM: 25
  • Java: 25
  • Spring Boot: 3.5.13
  • Kubernetes: v1.30.5
Logs

Example error:

io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: Deadline CallOptions was exceeded after 9.999786125s

主要言語
Java
スター
434
フォーク
260
平均マージ
2日 18時間
マージ済み PR（30日）
24

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

temporalio/sdk-java のほかの issue

temporalio/sdk-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。