google-api-core: AsyncBidiRpc.open() after the call ends leaves the previous request generator pending forever
メンテナーはふだん 1 日以内に返信
@shaashankrg がすでに取り組んでいます。
2026年11月10日 から。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- grpc, python
調査の方向性
Start in google/api_core/bidi_async.py, where AsyncBidiRpc.open() reuses self._request_queue and _AsyncRequestQueueGenerator is created for each call, and close() puts a single None sentinel. The grpc side is grpc/aio/_call.py, where _StreamRequestMixin.cancel() only cancels the request poller when super().cancel() returns True. Run the repro in the issue on Python 3.12 and check that the pending _consume_request_iterator tasks drop to 0 after close(). Done means each previous request generator ends on reopen or close, with no pending-task warnings.
索引モデルが issue の本文から書いたものです。
説明
Determine this is the right repository
- I determined this is the correct repository in which to report this bug.
Summary of the issue
Context
We consume Pub/Sub StreamingPull through google.api_core.bidi_async.AsyncBidiRpc. When the call ends (server EOF or a retryable error), we call open() again on the same AsyncBidiRpc. Nothing in the class documents that it can't be reopened.
Expected Behavior:
Reopening (and later close()) ends the request generator of each previous call, so grpc's request poller tasks for finished calls exit.
Actual Behavior:
Each open() creates a new _AsyncRequestQueueGenerator on the same _request_queue and never ends the previous one. grpc's _consume_request_iterator task for the finished call stays blocked in queue.get(). call.cancel() returns False on a finished call, so grpc never cancels that poller. close() puts a single None on the queue, which ends at most one generator.
When the AsyncBidiRpc is garbage-collected, asyncio reports Task was destroyed but it is pending! for each leaked poller. On Python 3.12 the async-generator finalizer then fails with RuntimeError: aclose(): asynchronous generator is already running, reported as "Task exception was never retrieved". Applications whose loop exception handler treats task exceptions as fatal shut down. In our case, this restarted streaming consumers across our fleet.
API client name and version
google-api-core v2.44.0 (also reproduced on v2.43.0), grpcio 1.84.1
Reproduction steps: code
file: main.py
import asyncio
import gc
import grpc
from google.api_core import bidi_async
METHOD = "/repro.Echo/Stream"
EOFS = 3
async def stream(request_iterator, context):
# End the call after the first request, as a server ending StreamingPull would.
async for request in request_iterator:
yield request
return
class Handler(grpc.GenericRpcHandler):
def service(self, details):
if details.method != METHOD:
return None
return grpc.stream_stream_rpc_method_handler(stream)
def report(loop, context):
exc = context.get("exception")
print(f"loop exception handler: {context['message']!r} {exc!r}")
async def reproduce():
asyncio.get_running_loop().set_exception_handler(report)
server = grpc.aio.server()
server.add_generic_rpc_handlers([Handler()])
port = server.add_insecure_port("127.0.0.1:0")
await server.start()
channel = grpc.aio.insecure_channel(f"127.0.0.1:{port}")
multicallable = channel.stream_stream(METHOD)
async def start_rpc(requests, metadata=None):
# Awaitable, like a generated async client's streaming method.
return multicallable(requests, metadata=metadata)
rpc = bidi_async.AsyncBidiRpc(start_rpc, initial_request=b"hello")
for _ in range(EOFS):
# Reopen the same AsyncBidiRpc after the server ends the call.
await rpc.open()
while await rpc.recv() is not grpc.aio.EOF:
pass
await asyncio.sleep(0.05)
await rpc.close()
await asyncio.sleep(0.05)
pending = [
t for t in asyncio.all_tasks() if "_consume_request_iterator" in repr(t.get_coro())
]
print(f"request pollers still pending after close(): {len(pending)}")
del rpc, pending
gc.collect()
await asyncio.sleep(0.05)
gc.collect()
await asyncio.sleep(0.05)
await channel.close()
await server.stop(None)
if __name__ == "__main__":
asyncio.run(reproduce())
Run: pip install "google-api-core[grpc]==2.44.0" grpcio==1.84.1 && python main.py
Reproduction steps: supporting files
None. The repro starts its own local grpc.aio server, with raw-bytes messages and no protos.
Reproduction steps: actual results
Python 3.12.14:
request pollers still pending after close(): 2
loop exception handler: 'Task was destroyed but it is pending!' None
loop exception handler: 'Task was destroyed but it is pending!' None
loop exception handler: 'Task exception was never retrieved' RuntimeError('aclose(): asynchronous generator is already running')
loop exception handler: 'Task exception was never retrieved' RuntimeError('aclose(): asynchronous generator is already running')
Python 3.13.14 (pending tasks only, no aclose error):
request pollers still pending after close(): 2
loop exception handler: 'Task was destroyed but it is pending!' None
loop exception handler: 'Task was destroyed but it is pending!' None
Reproduction steps: expected results
request pollers still pending after close(): 0
No loop exception handler output.
OS & version + platform
Production: Debian (python:3.12-slim image) on GKE. The repro also fails on macOS 26 (arm64).
Python environment
Python 3.12.14 (also 3.13.14)
Python dependencies
Package Version
certifi 2026.10.23
cffi 2.1.1
charset-normalizer 3.5.2
cryptography 50.0.2
google-api-core 2.44.0
google-auth 2.62.1
googleapis-common-protos 1.76.0
grpcio 1.84.1
grpcio-status 1.84.1
idna 3.20
opentelemetry-api 1.45.2
proto-plus 1.29.0
protobuf 7.36.2
pyasn1 0.6.5
pyasn1_modules 0.4.2
pycparser 3.12
requests 2.34.2
typing_extensions 4.16.0
urllib3 2.8.0
Additional context
- Relevant code:
google/api_core/bidi_async.py.AsyncBidiRpc.open()reusesself._request_queuefor every new_AsyncRequestQueueGenerator, andclose()puts oneNonesentinel. On the grpc side,grpc/aio/_call.py_StreamRequestMixin.cancel()only cancels_async_request_pollerwhensuper().cancel()returns True, which is false once the call has finished. - Possible fixes: end the previous request generator in
open()(for example, a sentinel on the old queue, or a fresh queue per open), or document that anAsyncBidiRpcmust not be reopened after its call ends. - Workaround: create a new
AsyncBidiRpcfor each reopen. We do this now.
- 主要言語
- Python
- スター
- 5.4k
- フォーク
- 1.8k
- 平均マージ
- 2日 7時間
- マージ済み PR(30日)
- 173
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
googleapis/google-cloud-python のほかの issue
-
firestore: field path with a quoted name ending in a backslash is misparsed対応中かも @sebxt が 25 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
googleapis/google-cloud-python#18771 ·
メンテナーはふだん 1 日以内に返信
-
api: spanner type: feature request
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
googleapis/google-cloud-python#18584 ·
メンテナーはふだん 1 日以内に返信
-
auth: `impersonated_credentials` loses `subject` on copy, so `with_scopes()` and `with_quota_project()` turn off domain wide delegation対応中かも @Om-singhaI が 55 日前に担当しました。 オープンauth priority: p2 type: bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
googleapis/google-cloud-python#18428 ·
メンテナーはふだん 1 日以内に返信
-
A client called `run_in_transaction` be stuck if Spanner is down対応中かも @founderinaction が 7 日前に担当しました。 オープンpriority: p2 type: bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
googleapis/google-cloud-python#18375 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
ci: enable --strict flag in presubmit twine_check再び着手できるかも @ohmayr が 44 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 76/100
googleapis/google-cloud-python#18339 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
googleapis/google-cloud-python の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
cpp-best-practices/project_validator#267 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
メンテナーはふだん 1 日以内に返信
-
[Bug] Sending a Telegram message chain twice duplicates mentions対応中かも @123XieC が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
AstrBotDevs/AstrBot#11125 ·
メンテナーはふだん 1 日以内に返信
-
backend bug priority: high
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
nooriegarg/ContribIQ#73 ·
メンテナーはふだん 1 日以内に返信
-
bug p3 security
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信