[
https://issues.apache.org/jira/browse/PHOENIX-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-7834:
----------------------------------
Fix Version/s: 5.3.2
(was: 5.3.1)
> CDCBaseIT do not force-delete a never-upserted row
> --------------------------------------------------
>
> Key: PHOENIX-7834
> URL: https://issues.apache.org/jira/browse/PHOENIX-7834
> Project: Phoenix
> Issue Type: Sub-task
> Components: test
> Reporter: Andrew Kyle Purtell
> Assignee: Andrew Kyle Purtell
> Priority: Minor
> Fix For: 5.4.0, 5.3.2
>
>
> {{CDCBaseIT.generateMutations}} has a second-half "force a delete if there
> was none so far" branch that flips {{isDelete=true}} without checking whether
> the candidate row was ever upserted in this run, so when random batch
> participation has skipped a key in every prior batch the forced {{DELETE}}
> lands on a non-existent row and produces an HBase tombstone with no matching
> put. The data table view sees no change, and a later legitimate upsert for
> the same key surfaces as the next CDC change event on a {{forView=true}} CDC
> while the expected change list still has the tombstone marked as a delete,
> tripping {{CDCBaseIT.verifyChangesViaSCN}} with {{{}ComparisonFailure
> expected:<delete> but was:<upsert> in
> CDCQueryIT.testSelectGeneric[forView=true,
> encodingScheme=TWO_BYTE_QUALIFIERS, multitenant=false, tableSaltBuckets=null,
> withSchemaName=false, caseSensitiveNames=false]{}}}. The fix gates the
> forced-delete branch on {{mutatedRows.contains(rows.get(j))}} so a delete is
> only ever forced on a row that has already been upserted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
