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

[Bug]: SpannerIO Change Streams may skip ChildPartitionsRecord when advancing tracker to artificial query end timestamp

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

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
google-cloud, java
領域
backend, databases, stream-processing

調査の方向性

The issue is in QueryChangeStreamAction.java around line 360. Start by understanding the restriction tracker and how it claims timestamps. Look at the logic for unbounded queries when stopAfterQuerySucceeds is false. The fix is to avoid advancing the tracker to the artificial changeStreamQueryEndTimestamp and instead leave it at the last claimed position. Run tests related to Spanner Change Streams to verify the fix doesn't break existing behavior.

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

説明

io java P1
What happened?

When reading from an unbounded Spanner Change Stream (or a Mutable Change Stream with a capped query end timestamp), QueryChangeStreamAction issues change stream queries with an artificial changeStreamQueryEndTimestamp (now + 2 minutes).

Previously, when the query completed and needed to resume (!stopAfterQuerySucceeds), QueryChangeStreamAction called tracker.tryClaim(changeStreamQueryEndTimestamp) before returning ProcessContinuation.resume():

https://github.com/apache/beam/blob/ac4acbb6282/sdks/java/io/google-cloud-platform/src/main/java/org/apache/beam/sdk/io/gcp/spanner/changestreams/action/QueryChangeStreamAction.java#L360-L365

In a very rare timing corner case where a change stream query finishes without returning the ChildPartitionsRecord at the end of a partition's range, claiming changeStreamQueryEndTimestamp can advance the restriction tracker past the partition's actual end timestamp. On the next continuation, the query resumes from changeStreamQueryEndTimestamp + 1ns, which falls outside the partition's valid timestamp range and returns an out-of-range start_timestamp error, causing QueryChangeStreamAction to mark the partition FINISHED before scheduling its child partitions.

Workaround & Scope

This is a client-side workaround in Apache Beam for this rare edge case while a fix is being implemented on the Spanner server side:

  • Unbounded queries: When !stopAfterQuerySucceeds, leaving the restriction tracker at the last claimed position (from the last processed data or heartbeat record) instead of advancing to changeStreamQueryEndTimestamp ensures the subsequent query resumes from lastClaimedTimestamp + 1ns and reads any remaining records (including ChildPartitionsRecord) before the partition ends. This workaround addresses the issue for unbounded queries.
  • Bounded queries: For bounded queries where changeStreamQueryEndTimestamp reaches endTimestamp (stopAfterQuerySucceeds == true), this client-side workaround does not apply and will be addressed by the Spanner server-side fix.
Issue Priority

Priority: 2 (default / most bugs should be filed as P2)

Issue Components
  • Component: Java SDK
  • Component: IO Connectors
主要言語
Java
スター
8.7k
フォーク
4.7k
平均マージ
2日 16時間
マージ済み PR（30日）
253

環境構築

はじめの一歩

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

apache/beam のほかの issue

apache/beam の issue をすべて見る

似ている issue

Java の issue をもっと見る

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

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