[
https://issues.apache.org/jira/browse/BEAM-13606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470854#comment-17470854
]
Ning commented on BEAM-13606:
-----------------------------
When no retryable error is raised, the client does set OK status for successful
mutations and if there is any error but not retryable, they are also set.
Though it seems that if rows are batched/flushed together, they will share the
same None value returned by the client even if only one of the rows run into
retryable error. The real row mutation happens in this RPC [1].
See how the try-except skips all following codes that populates the responses
from the RPC to the responses returned by the client.
[1]
https://github.com/googleapis/python-bigtable/blob/fec06fcd28c36d0d3b347b43d1f3d264e5f5aa39/google/cloud/bigtable/table.py#L1126
> bigtable io doesn't handle non-ok row mutations
> -----------------------------------------------
>
> Key: BEAM-13606
> URL: https://issues.apache.org/jira/browse/BEAM-13606
> Project: Beam
> Issue Type: Bug
> Components: io-py-gcp
> Reporter: Ning
> Assignee: Chamikara Madhusanka Jayalath
> Priority: P1
>
> bigtable io has no logic to retry row mutations for rows with non-ok return
> status (this includes None return value when bigtable suppresses retryable
> errors, details see BEAM-13602).
>
> To avoid data loss, the solution should be:
> # Retry for those retryable-failed row mutations;
> # Tagged output for those non-retryable-failed row mutations.
> Or clarify that the I/O doesn't handle failed row mutations in docstrings.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
