[PR] PHOENIX-7894 Set EXPECTED_UPPER_REGION_KEY on local index scans [phoenix]

["apurtell (via GitHub)" <gi...@apache.org>]

apurtell opened a new pull request, #2632:
URL: https://github.com/apache/phoenix/pull/2632

   The local index stale region check falls back to the scan stop row when EXPECTED_UPPER_REGION_KEY is absent. Reversed scans are swapped on the client, so the stop row is the region start key and every region looks stale.
   
   Set the attribute to the region end key in setLocalIndexAttributes so the check is direction independent. When the check passes, setupLocalIndexScan must also accept the swapped boundaries. Take the prefix from the region start key in both directions. For a reversed scan, put the stop row suffix in the start row.
   
   Co-Authored-By: Claude Opus 5.5 <no...@anthropic.com>
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@phoenix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] PHOENIX-7894 Set EXPECTED_UPPER_REGION_KEY on local index scans [phoenix]

["Copilot (via GitHub)" <gi...@apache.org>]

Copilot commented on code in PR #2632:
URL: https://github.com/apache/phoenix/pull/2632#discussion_r4225603112


##########
phoenix-core-client/src/main/java/org/apache/phoenix/util/ScanUtil.java:
##########
@@ -948,6 +963,7 @@ public static void setLocalIndexAttributes(Scan newScan, int keyOffset, byte[] r
     byte[] regionEndKey, byte[] startRowSuffix, byte[] stopRowSuffix) {
     if (ScanUtil.isLocalIndex(newScan)) {
       newScan.setAttribute(SCAN_ACTUAL_START_ROW, regionStartKey);
+      newScan.setAttribute(EXPECTED_UPPER_REGION_KEY, regionEndKey);

Review Comment:
   `setScanAttributesForPhoenixTTL` invokes this method again at `ScanUtil.java:1608` with `HConstants.EMPTY_BYTE_ARRAY` as `regionEndKey`, after `BaseResultIterators` has populated the real per-region end key. When a local index has a serializable TTL expression, this assignment overwrites that real key, so every non-final region fails the server-side comparison and is reported stale. Preserve/pass through the existing expected upper key during the TTL rewrap instead of replacing it with the empty boundary.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@phoenix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] PHOENIX-7894 Set EXPECTED_UPPER_REGION_KEY on local index scans [phoenix]

["Copilot (via GitHub)" <gi...@apache.org>]

Copilot commented on code in PR #2632:
URL: https://github.com/apache/phoenix/pull/2632#discussion_r4225547153


##########
phoenix-core-server/src/main/java/org/apache/phoenix/coprocessor/BaseScannerRegionObserver.java:
##########
@@ -89,7 +91,8 @@ private static void throwIfScanOutOfRegion(Scan scan, Region region)
     if (isLocalIndex) {
       // For local indexes we have to abort any scan that was open during a split.
       // We detect that condition as follows:
-      // 1. The scanner's stop row has to always match the region's end key.
+      // 1. The EXPECTED_UPPER_REGION_KEY attribute has to always match the region's end key.
+      // Older clients do not set the attribute. For them, the scan's stop row is the fallback.

Review Comment:
   The fallback still breaks reversed scans from older clients that already perform the client-side boundary swap but do not send `EXPECTED_UPPER_REGION_KEY`: their region end key is in `getStartRow()`, while `getStopRow()` is the region start key, so every non-degenerate region is rejected as stale. Since the comment explicitly preserves older-client compatibility, select the fallback by `scan.isReversed()` (and add the corresponding reversed compatibility case to the test).



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@phoenix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org