gRPC-JS client hangs when target server restarts

オープン

#2,785 2024年7月4日に作成コメント 5 件リアクション 0 件担当者 0 名 GitHub で見る

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

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

評価

難易度: 4/5
見積もり時間: 3〜5日
初心者へのやさしさ: 35/100

issue の種類: バグ
明瞭さ: 説明が足りない
活発さ: 活発
技術スタック: nginx, node.js, typescript
領域: backend-api-design, networking

調査の方向性

報告では、リポジトリのファイルもテストも特定されていません。まず、gRPC-JS 1.19.15、Node 18/22、NLB/nginx パス、および提供された keepalive オプションを使用して再起動シーケンスを再現し、復旧前後のトレースを比較してください。クライアント A を再起動せずにリクエストが再開し、回帰テストまたは再現可能なプロジェクトによって修正が実証されれば完了です。

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

説明

package: @grpc/grpc-js requires reporter action

Problem description

gRPC js client freezes on server disconnections, require full client restarts

Reproduction steps

We have a server (server API is gRPC, using malijs), let's call it A which calls a gRPC target proxied by an NLB and nginx gRPC ingress, let's call it B. If we go ahead and restart the target instances of B, The client might sometime hang, resulting in the application A failing to function. All flows calling to A that will result in A calling B will hang

The moment we restart A, it becomes functioning, meaning it's a client state issue.

Environment

Debian 11/12 based containers
Node version: 18.20.x and 22.2.x
NVM based installation
gRPC-JS 1.19.15
Client options: { 'grpc.keepalive_time_ms': 10_000, 'grpc.max_receive_message_length': 64 * 1024 * 1024 }

Additional context

We've activated gRPC tracing on server A

here's what a normal server selection trace looks like:

D 2024-07-04T09:37:26.487Z | v1.9.15 29 | subchannel | (157) 10.41.10.107:443 READY -> IDLE
D 2024-07-04T09:37:26.487Z | v1.9.15 29 | subchannel_refcount | (157) 10.41.10.107:443 refcount 2 -> 1
D 2024-07-04T09:37:26.487Z | v1.9.15 29 | pick_first | READY -> IDLE
D 2024-07-04T09:37:26.487Z | v1.9.15 29 | resolving_load_balancer | dns:service-b.internal.com:443 READY -> IDLE
D 2024-07-04T09:37:26.487Z | v1.9.15 29 | connectivity_state | (2) dns:service-b.internal.com:443 READY -> IDLE
D 2024-07-04T09:37:26.487Z | v1.9.15 29 | dns_resolver | Looking up DNS hostname service-b.internal.com
D 2024-07-04T09:37:26.487Z | v1.9.15 29 | resolving_load_balancer | dns:service-b.internal.com:443 IDLE -> CONNECTING
D 2024-07-04T09:37:26.487Z | v1.9.15 29 | connectivity_state | (2) dns:service-b.internal.com:443 IDLE -> CONNECTING
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | dns_resolver | Resolved addresses for target dns:service-b.internal.com:443: [10.41.33.32:443,10.41.22.168:443,10.41.10.107:443]
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | subchannel | (202) 10.41.33.32:443 Subchannel constructed with options {}
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | subchannel_refcount | (202) 10.41.33.32:443 refcount 0 -> 1
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | subchannel | (203) 10.41.22.168:443 Subchannel constructed with options {}
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | subchannel_refcount | (203) 10.41.22.168:443 refcount 0 -> 1
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | subchannel_refcount | (202) 10.41.33.32:443 refcount 1 -> 2
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | subchannel_refcount | (203) 10.41.22.168:443 refcount 1 -> 2
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | subchannel_refcount | (157) 10.41.10.107:443 refcount 1 -> 2
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | pick_first | Start connecting to subchannel with address 10.41.33.32:443
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | pick_first | IDLE -> CONNECTING
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | resolving_load_balancer | dns:service-b.internal.com:443 CONNECTING -> CONNECTING
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | connectivity_state | (2) dns:service-b.internal.com:443 CONNECTING -> CONNECTING
D 2024-07-04T09:37:26.492Z | v1.9.15 29 | subchannel | (202) 10.41.33.32:443 IDLE -> CONNECTING
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | subchannel | (202) 10.41.33.32:443 CONNECTING -> READY
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | pick_first | Pick subchannel with address 10.41.33.32:443
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | subchannel_refcount | (202) 10.41.33.32:443 refcount 2 -> 3
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | subchannel_refcount | (202) 10.41.33.32:443 refcount 3 -> 2
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | subchannel_refcount | (203) 10.41.22.168:443 refcount 2 -> 1
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | subchannel_refcount | (157) 10.41.10.107:443 refcount 2 -> 1
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | pick_first | CONNECTING -> READY
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | resolving_load_balancer | dns:service-b.internal.com:443 CONNECTING -> READY
D 2024-07-04T09:37:26.499Z | v1.9.15 29 | connectivity_state | (2) dns:service-b.internal.com:443 CONNECTING -> READY
D 2024-07-04T09:37:30.637Z | v1.9.15 29 | subchannel_refcount | (157) 10.41.10.107:443 refcount 1 -> 0

As expected, connections enter into TRANSIENT_FAILURE state once I kill the target pods B. When they become responsive again, We get these messages:

D 2024-07-04T09:47:31.084Z | v1.9.15 29 | subchannel | (299) 10.41.22.168:443 CONNECTING -> TRANSIENT_FAILURE
D 2024-07-04T09:47:31.084Z | v1.9.15 29 | subchannel | (299) 10.41.22.168:443 TRANSIENT_FAILURE -> IDLE
D 2024-07-04T09:47:31.084Z | v1.9.15 29 | subchannel | (299) 10.41.22.168:443 IDLE -> CONNECTING
D 2024-07-04T09:47:31.084Z | v1.9.15 29 | subchannel | (300) 10.41.33.32:443 CONNECTING -> TRANSIENT_FAILURE
D 2024-07-04T09:47:31.084Z | v1.9.15 29 | subchannel | (300) 10.41.33.32:443 TRANSIENT_FAILURE -> IDLE
D 2024-07-04T09:47:31.084Z | v1.9.15 29 | subchannel | (300) 10.41.33.32:443 IDLE -> CONNECTING
D 2024-07-04T09:47:31.093Z | v1.9.15 29 | subchannel | (300) 10.41.33.32:443 CONNECTING -> READY
D 2024-07-04T09:47:31.094Z | v1.9.15 29 | pick_first | Pick subchannel with address 10.41.33.32:443
D 2024-07-04T09:47:31.094Z | v1.9.15 29 | subchannel_refcount | (300) 10.41.33.32:443 refcount 2 -> 3
D 2024-07-04T09:47:31.094Z | v1.9.15 29 | subchannel_refcount | (275) 10.41.10.107:443 refcount 2 -> 1
D 2024-07-04T09:47:31.094Z | v1.9.15 29 | subchannel_refcount | (300) 10.41.33.32:443 refcount 3 -> 2
D 2024-07-04T09:47:31.094Z | v1.9.15 29 | subchannel_refcount | (299) 10.41.22.168:443 refcount 2 -> 1
D 2024-07-04T09:47:31.094Z | v1.9.15 29 | pick_first | TRANSIENT_FAILURE -> READY
D 2024-07-04T09:47:31.094Z | v1.9.15 29 | resolving_load_balancer | dns:service-b.internal.com:443 TRANSIENT_FAILURE -> READY
D 2024-07-04T09:47:31.094Z | v1.9.15 29 | connectivity_state | (2) dns:service-b.internal.com:443 TRANSIENT_FAILURE -> READY
D 2024-07-04T09:47:31.109Z | v1.9.15 29 | subchannel | (299) 10.41.22.168:443 CONNECTING -> READY

And from that moment on, we stop seeing these messages altogether. As though the driver becomes stuck.

We still see these traces

D 2024-07-04T09:43:57.000Z | v1.9.15 29 | channel | (2) dns:service-b.internal.com:443 createResolvingCall [272] method="...", deadline=Infinity
D 2024-07-04T09:43:57.001Z | v1.9.15 29 | channel | (2) dns:service-b.internal.com:443 createRetryingCall [273] method="..."
D 2024-07-04T09:43:57.001Z | v1.9.15 29 | channel | (2) dns:service-b.internal.com:443 createLoadBalancingCall [274] method="..."

but no request is actuall being sent, the client is completely frozen. Any help will be much obliged

主要言語: TypeScript
スター: 4.8k
フォーク: 716
平均マージ: 1日 18時間
マージ済み PR（30日）: 17

環境構築

コントリビューションガイドを読む

はじめの一歩

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

grpc/grpc-node のほかの issue

CompressionFilter’s IdentityHandler.writeMessage calls Buffer-only .copy() on caller-provided message
オープン
- 何か問題がありますか？
難易度 2/5 1〜3時間初心者へのやさしさ 82/100

grpc/grpc-node#3050 · 2026年5月14日に作成

メンテナーはふだん 2 日以内に返信
`createFromGoogleCredential` is not compatible with `google-auth-library` 10.x.x
オープン
- 何か問題がありますか？
package: @grpc/grpc-js

難易度 2/5 1〜3時間初心者へのやさしさ 62/100

grpc/grpc-node#2993 · コメント 3 件 · リアクション 4 件 · 2025年8月5日に作成

メンテナーはふだん 2 日以内に返信
Error during response serialization discards stack trace
オープン
- 何か問題がありますか？
難易度 3/5 1〜2日初心者へのやさしさ 65/100

grpc/grpc-node#3091 · リアクション 1 件 · 2026年9月23日に作成

メンテナーはふだん 2 日以内に返信
Typescript Type generation not working using proto-loader-gen-types
オープン
- 何か問題がありますか？
feature request

難易度 3/5 1〜2日初心者へのやさしさ 68/100

grpc/grpc-node#3077 · コメント 1 件 · 2026年9月3日に作成

メンテナーはふだん 2 日以内に返信
Keepalive PING after graceful GOAWAY disconnects draining RPCs
オープン
- 何か問題がありますか？
難易度 3/5 1〜2日初心者へのやさしさ 76/100

grpc/grpc-node#3068 · コメント 2 件 · リアクション 1 件 · 2026年7月15日に作成

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

grpc/grpc-node の issue をすべて見る

似ている issue

Files & Videos: overflow-x: visible on the DataTable makes the page scroll horizontally on phones (More-info popup not portaled)
オープン
- 何か問題がありますか？
難易度 2/5 1〜3時間初心者へのやさしさ 88/100

openedx/frontend-app-authoring#3274 · 2026年9月29日に作成

メンテナーはふだん 1 日以内に返信
🎙️ task - fix(deployer): deploy --env prep runs deploy:dev where the repo declares deploy:prep
オープン
- 何か問題がありますか？
難易度 2/5 1〜3時間初心者へのやさしさ 88/100

ehmpathy/rhachet-roles-ghlitch#137 · 2026年9月29日に作成
`.gemini/skills/behavioral-evals/SKILL.md` links to a contributor's local `file://` path
オープン
- 何か問題がありますか？
area/documentation status/need-triage

難易度 1/5 1時間未満初心者へのやさしさ 95/100

google-gemini/gemini-cli#29548 · 2026年9月29日に作成

メンテナーはふだん 1 日以内に返信
TS SDK: Qdrant search fails with @qdrant/js-client-rest 1.19 (client.search removed)
オープン
- 何か問題がありますか？
sdk-typescript vector-store

難易度 2/5 半日初心者へのやさしさ 82/100

mem0ai/mem0#7495 · コメント 1 件 · 2026年9月29日に作成

メンテナーはふだん 1 日以内に返信
File backend multipart completion concatenates parts in request order
オープン
- 何か問題がありますか？
難易度 2/5 1〜3時間初心者へのやさしさ 82/100

supabase/storage#1453 · 2026年9月29日に作成

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

TypeScript の issue をもっと見る

gRPC-JS client hangs when target server restarts

何か問題がありますか？

評価

調査の方向性

説明

Problem description

Reproduction steps

Environment

Additional context

環境構築

はじめの一歩

grpc/grpc-node のほかの issue

何か問題がありますか？

何か問題がありますか？

何か問題がありますか？

何か問題がありますか？

何か問題がありますか？

似ている issue

何か問題がありますか？

何か問題がありますか？

何か問題がありますか？

何か問題がありますか？

何か問題がありますか？

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