I'm at the point with the HBase 3 work where most of the failing tests are because of tests depending on HBase 2.x implementation details.
ScanUncommittedWithRegionMovesIT is one that is failing with HBase 3, but I think that it is testing a behaviour that HBase does not guarantee. It claims to test for READ_COMMITTED behaviour, but I think that it is instead testing for SERIALIZABLE behaviour (and fails on HBase 3) It starts a Connection and query and keeps moving regions between regionservers, while it writes some more records from an other Connection, and expects to see only the original records in the first query. (Not using Omid) IMO that's testing for SERIALIZABLE behaviour, not READ_COMMITTED. The records from the second connection were written and "committed" at that point, and there is no expectation either from HBase or Phoenix to guarantee that they are not visible from the first query. Normally they are not visible, because the scans cache a number of rows, but moving around the regions and re-starting the scans clears the caches, and can make the committed cells from the second connections visible. Now the question here is why does this test work with HBase 2.x, and I don't have an answer beyond that the scans are possibly restarted at different points. I think that this test is invalid, and should be removed. Do you agree ? Do you think that this test is valid ? If yes, then by what mechanism is the expected SERIALIZABLE behaviour implemented ? I have opened https://issues.apache.org/jira/browse/HBASE-29839 to remove this test. Istvan
