Repository navigation
fix(bigtable/bttest): honor timestamp_origin on SetCell - #20469
Merged
mutianf merged 1 commit intoSep 8, 2026
Merged
Conversation
data.proto specifies that the server truncates a CLIENT_AUTO_GENERATED timestamp to the table's granularity, and rejects only a USER_SPECIFIED one whose precision does not match. bttest did not read the field, so it truncated the TimestampMicros == -1 case alone and rejected everything else that was not aligned. That is reachable from a released client: google-cloud-bigtable (Java) 2.82.0 changed the writer-clock setCell overload to a microsecond Instant.now() and marks those mutations CLIENT_AUTO_GENERATED, so the default write path now succeeds against the service and fails against the emulator. applyMutations is shared by MutateRow, MutateRows and CheckAndMutateRow, so one place covers all three. AddToCell and MergeToCell are unaffected: their timestamps are user-supplied by construction. Fixes googleapis#20468
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the Bigtable in-memory test server (bttest) to support the TimestampOrigin field on mutations. Specifically, when the origin is CLIENT_AUTO_GENERATED, the server now truncates the timestamp to match the table's granularity instead of rejecting it, adhering to the Bigtable API contract. A new test suite has been added to verify this behavior. There are no review comments to address, and I have no additional feedback to provide.
mutianf
approved these changes
Sep 3, 2026
Contributor
|
Thanks for the fix. |
sushanb
approved these changes
Sep 8, 2026
dbolduc
pushed a commit
that referenced
this pull request
Sep 10, 2026
🤖 I have created a release *beep* *boop* --- ## [1.57.0](bigtable/v1.56.0...bigtable/v1.57.0) (2026-09-10) ### Features * **bigtable:** Build the accelerator daemon for Windows ([#20455](#20455)) ([df55af5](df55af5)) ### Bug Fixes * **bigtable/bttest:** Honor timestamp_origin on SetCell ([#20469](#20469)) ([528aaf8](528aaf8)), refs [#20468](#20468) * **bigtable:** Keep single-key ReadRows on the streaming classic path ([#20506](#20506)) ([2bfdb5d](2bfdb5d)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
laughingman7743
added a commit
to flink-gcp/flink-connector-gcp
that referenced
this pull request
Oct 11, 2026
…around WHAT: The Pub/Sub, Firestore and Bigtable emulator images move from google-cloud-cli 587.0.0-emulators to 588.0.0-emulators. The Bigtable harness drops harnessTimestampMicros and writes through the timestamp-less setCell overloads. BigtableEmulatorDeviationITCase replaces the pin of the old rejection with truncatesAClientGeneratedTimestampAsTheServiceDoes, which also asserts that an unaligned timestamp actually went on the wire; it deletes the client-rounding pin its own comment scheduled for removal and follows the emulator's new wording for an explicit unaligned timestamp. ADR-0149 records the change, and the Bigtable deviation table drops the row that no longer differs. WHY: Up to 587.0.0 the Bigtable emulator ignored Mutation.timestamp_origin and refused a client-auto-generated microsecond timestamp that real Bigtable truncates, so the harness stamped an explicit one (#1205). The upstream fix (googleapis/google-cloud-go#20469) is in 588.0.0: measured on 2026-10-11, the emulator accepts such a timestamp and stores it truncated to a millisecond, as the service does, while an explicit unaligned timestamp is still refused for that entry alone with INTERNAL. The new pin fails against 587.0.0, so losing the parity in a later image would be reported. The full build passes on 588.0.0. Closes #1205 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
laughingman7743
added a commit
to flink-gcp/flink-connector-gcp
that referenced
this pull request
Oct 11, 2026
…around WHAT: The Pub/Sub, Firestore and Bigtable emulator images move from google-cloud-cli 587.0.0-emulators to 588.0.0-emulators. The Bigtable harness drops harnessTimestampMicros and writes through the timestamp-less setCell overloads. BigtableEmulatorDeviationITCase replaces the pin of the old rejection with truncatesAClientGeneratedTimestampAsTheServiceDoes, which also asserts that an unaligned timestamp actually went on the wire; it deletes the client-rounding pin its own comment scheduled for removal and follows the emulator's new wording for an explicit unaligned timestamp. ADR-0149 records the change, and the Bigtable deviation table drops the row that no longer differs. WHY: Up to 587.0.0 the Bigtable emulator ignored Mutation.timestamp_origin and refused a client-auto-generated microsecond timestamp that real Bigtable truncates, so the harness stamped an explicit one (#1205). After the upstream fix (googleapis/google-cloud-go#20469), 588.0.0 is the first image that behaves accordingly: measured on 2026-10-11, the emulator accepts such a timestamp and stores it truncated to a millisecond, as the service does, while an explicit unaligned timestamp is still refused for that entry alone with INTERNAL. The new pin fails against 587.0.0, so losing the parity in a later image would be reported. The full build passes on 588.0.0. Closes #1205 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
laughingman7743
added a commit
to flink-gcp/flink-connector-gcp
that referenced
this pull request
Oct 11, 2026
…around WHAT: The Pub/Sub, Firestore and Bigtable emulator images move from google-cloud-cli 587.0.0-emulators to 588.0.0-emulators. The Bigtable harness drops harnessTimestampMicros and writes through the timestamp-less setCell overloads. BigtableEmulatorDeviationITCase replaces the pin of the old rejection with truncatesAClientGeneratedTimestampAsTheServiceDoes, which records the timestamp each write sent and asserts that one of them was not a whole millisecond and that each row stored its own truncated; it deletes the client-rounding pin its own comment scheduled for removal and follows the emulator's new wording for an explicit unaligned timestamp. ADR-0149 records the change, and the Bigtable deviation table drops the row that no longer differs. WHY: Up to 587.0.0 the Bigtable emulator ignored Mutation.timestamp_origin and refused a client-auto-generated microsecond timestamp that real Bigtable truncates, so the harness stamped an explicit one (#1205). After the upstream fix (googleapis/google-cloud-go#20469), 588.0.0 is the first image that behaves accordingly: measured on 2026-10-11, the emulator accepts such a timestamp and stores it truncated to a millisecond, as the service does, while an explicit unaligned timestamp is still refused for that entry alone with INTERNAL. The new pin fails against 587.0.0, so losing the parity in a later image would be reported. The full build passes on 588.0.0. Closes #1205 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows the principle #20456 established for
TimestampMicros == -1— "Server-generatedtimestamps ... are truncated to the table's granularity rather than rejected" — and applies it to
the second generated case, which
data.protodefines explicitly:USER_SPECIFIED— "The server will reject the mutation if the timestamp's precision does notmatch the table's granularity."
CLIENT_AUTO_GENERATED— "The server will truncate the timestamp's precision to match thetable's granularity."
bttestdid not readMutation.timestamp_originat all, so the second rule was not implemented.Measured both ends, 2026-09-03 (details in #20468):
MILLIStablebttest,MILLIStableInvalidArgument: invalid timestamp …applyMutationsis shared byMutateRow,MutateRowsandCheckAndMutateRow, so one placecovers all three.
AddToCellandMergeToCellare left alone: their timestamps are user-suppliedby construction.
The new test fails on exactly one case against the unpatched code —
millis table truncates a client-generated micros timestamp— and passes on the other four, which encode behaviour thatalready existed.
Fixes #20468