-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fix Python Bigtable dataloss bug] Stop unsetting timestamps of -1 #28624
Conversation
Run Python_Xlang_Gcp_Direct PostCommit |
Run Python_Xlang_Gcp_Dataflow PostCommit |
@@ -255,7 +255,7 @@ def process(self, direct_row): | |||
"value": mutation.set_cell.value | |||
} | |||
micros = mutation.set_cell.timestamp_micros | |||
if micros > -1: | |||
if micros >= -1: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this conditional? why isnt the timestamp just passed through?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot why it was originally set up like this, but I don't see a reason for it
Run Python_Xlang_Gcp_Direct PostCommit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm & thanks for the quick turnaround
Codecov Report
@@ Coverage Diff @@
## master #28624 +/- ##
==========================================
- Coverage 72.20% 72.20% -0.01%
==========================================
Files 684 684
Lines 101131 101130 -1
==========================================
- Hits 73023 73021 -2
- Misses 26529 26530 +1
Partials 1579 1579
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 5 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Assigning reviewers. If you would like to opt out of this review, comment R: @liferoad for label python. Available commands:
The PR bot will only process comments in the main thread (not review comments). |
Run Python_Xlang_Gcp_Direct PostCommit |
BigtableWriteSchemaTransform can be used in other cases (template, xlang other than python), should we set Timestamp to -1 if it is not provided in incoming row? Line 183 in f635ade
|
@Abacn I think that's a good call, will include it in this PR |
Run Python_Xlang_Gcp_Direct PostCommit |
fyi test passed on GitHub Action also: https://github.com/apache/beam/actions/runs/6280225908 Though current phrase trigger on GitHub Action is not conveniently visible (we're investigating a solution) |
Merging after Java_GCP_IO_Direct tests pass |
Failing tests are irrelevant, merging now |
} | ||
ByteString.copyFrom(ofNullable(mutation.get("family_name")).get())) | ||
// Use timestamp if provided, else default to -1 (current Bigtable server time) | ||
.setTimestampMicros( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: would the most appropriate logic be more like this?
if (mutation.containsKey("timestamp_micros")) {
builder.setTimestampMicros(mutation.get("timestamp_micros"));
}
and so on probably for all the fields, since proto handling of optional fields is not usable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could definitely add those checks, but want to point out that the input mutation map object is constructed here:
beam/sdks/python/apache_beam/io/gcp/bigtableio.py
Lines 249 to 258 in 68cf802
for mutation in direct_row._get_mutations(): | |
if mutation.__contains__("set_cell"): | |
mutation_dict = { | |
"type": b'SetCell', | |
"family_name": mutation.set_cell.family_name.encode('utf-8'), | |
"column_qualifier": mutation.set_cell.column_qualifier, | |
"value": mutation.set_cell.value, | |
"timestamp_micros": struct.pack( | |
'>q', mutation.set_cell.timestamp_micros) | |
} |
This process is internal, so we always expect these fields to exist (at least if we're talking xlang. I'm not aware of other ways SchemaTransforms are used). Users wouldn't be constructing their own Beam Row mutations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just mean to be a true passthrough, we pass "not present" to "not present" instead of putting the logic for choosing a default value into our code, where it is duplicated and could get out of sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure I can agree with that. I can address this nit in another PR but for now the current changes should be okay to cherry-pick?
@Abacn this means we'd have to make sure the Go wrapper defaults timestamps to time at ingestion. Also templates don't use the schematransform AFAIK so it shouldn't matter there anyways right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@igorbernstein2 cc'ing you to this thread as well cuz I heard the Go wrapper is implemented by the Bigtable team and maybe you can weigh in on this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is due to a different/inconsistent behavior in Java an Python API. We cannot "pass "not present" to "not present"". For Python, If timestamp not set it defaults to -1: https://github.com/googleapis/python-bigtable/blob/e5af3597f45fc4c094c59abca876374f5a866c1b/google/cloud/bigtable/row.py#L164
For Java, if timestamp not set it defaults to 0 and causing problem
Arguably the Documentation for Java client asks user to set Timestamp and warns that it will defaults to 0 if unspecified: https://github.com/googleapis/java-bigtable/blob/15cd4868ff807513914095a3758134eaa14f0ea3/proto-google-cloud-bigtable-v2/src/main/java/com/google/bigtable/v2/Mutation.java#L902
Consequently the possible misuse (did not set Timestamp and then data loss) could still happen in Java BigtableIO with user constructed Mutation: #27022
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be a useful action item to add validation somehow to prevent unset timestamp
Fixes #28632