Skip to content
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

Merged
merged 9 commits into from
Sep 23, 2023

Conversation

ahmedabu98
Copy link
Contributor

@ahmedabu98 ahmedabu98 commented Sep 22, 2023

Fixes #28632

@ahmedabu98
Copy link
Contributor Author

Run Python_Xlang_Gcp_Direct PostCommit

@ahmedabu98
Copy link
Contributor Author

Run Python_Xlang_Gcp_Dataflow PostCommit

@ahmedabu98 ahmedabu98 marked this pull request as ready for review September 22, 2023 20:08
@@ -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:
Copy link
Contributor

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?

Copy link
Contributor Author

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

@ahmedabu98
Copy link
Contributor Author

Run Python_Xlang_Gcp_Direct PostCommit

Copy link
Contributor

@igorbernstein2 igorbernstein2 left a 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
Copy link

codecov bot commented Sep 22, 2023

Codecov Report

Merging #28624 (deb221c) into master (426dbd3) will decrease coverage by 0.01%.
Report is 6 commits behind head on master.
The diff coverage is n/a.

@@            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              
Flag Coverage Δ
python 82.76% <ø> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed Coverage Δ
sdks/python/apache_beam/io/gcp/bigtableio.py 74.04% <ø> (-0.59%) ⬇️

... and 5 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@github-actions
Copy link
Contributor

Assigning reviewers. If you would like to opt out of this review, comment assign to next reviewer:

R: @liferoad for label python.
R: @bvolpato for label io.

Available commands:

  • stop reviewer notifications - opt out of the automated review tooling
  • remind me after tests pass - tag the comment author after tests pass
  • waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

@ahmedabu98
Copy link
Contributor Author

Run Python_Xlang_Gcp_Direct PostCommit

@Abacn
Copy link
Contributor

Abacn commented Sep 22, 2023

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?

@ahmedabu98
Copy link
Contributor Author

@Abacn I think that's a good call, will include it in this PR

@ahmedabu98
Copy link
Contributor Author

Run Python_Xlang_Gcp_Direct PostCommit

@github-actions github-actions bot added java and removed java labels Sep 23, 2023
@ahmedabu98 ahmedabu98 added this to the 2.51.0 Release milestone Sep 23, 2023
@Abacn
Copy link
Contributor

Abacn commented Sep 23, 2023

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)

@github-actions github-actions bot added the java label Sep 23, 2023
@ahmedabu98 ahmedabu98 changed the title [Python Bigtable dataloss bug] Stop unsetting timestamps of -1 [Fix Python Bigtable dataloss bug] Stop unsetting timestamps of -1 Sep 23, 2023
@ahmedabu98
Copy link
Contributor Author

Merging after Java_GCP_IO_Direct tests pass

@github-actions github-actions bot added java and removed java labels Sep 23, 2023
@ahmedabu98
Copy link
Contributor Author

Failing tests are irrelevant, merging now

@ahmedabu98 ahmedabu98 merged commit 68cf802 into apache:master Sep 23, 2023
89 of 92 checks passed
}
ByteString.copyFrom(ofNullable(mutation.get("family_name")).get()))
// Use timestamp if provided, else default to -1 (current Bigtable server time)
.setTimestampMicros(
Copy link
Member

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

Copy link
Contributor Author

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:

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

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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

Copy link
Contributor

@Abacn Abacn Sep 26, 2023

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

Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug][Python Bigtable Cross-language]: Connector mishandles records that don't explicitly set a timestamp
4 participants