Description
Saw the TestCloneSnapshotProcedureFileBasedSFT failing several times
2022-03-14T11:23:13,782 INFO [PEWorker-1] procedure2.ProcedureExecutor(1432): Finished pid=99, state=SUCCESS, hasLock=false; CloneSnapshotProcedure (table=testRecoverWithRestoreAclFlag snapshot=name: "snapshot-1647256973399" table: "testCloneSnapshot" creation_time: 1647256982366 type: FLUSH version: 2 owner: "" ttl: 0 max_file_size: 0 ) in 6.9090 sec 2022-03-14T11:23:13,794 WARN [PEWorker-1] procedure2.ProcedureExecutor$Testing(127): Toggle KILL before store update to: false 2022-03-14T11:23:13,794 DEBUG [PEWorker-1] procedure2.ProcedureExecutor(1777): TESTING: Kill BEFORE store update: pid=112, state=RUNNABLE:MODIFY_TABLE_DESCRIPTOR_UPDATE, hasLock=true; InitializeStoreFileTrackerProcedure table=testRecoverWithRestoreAclFlag 2022-03-14T11:23:13,794 INFO [PEWorker-1] procedure2.ProcedureExecutor(635): Stopping 2022-03-14T11:23:13,795 WARN [PEWorker-1] procedure2.ProcedureExecutor$WorkerThread(1997): Worker terminating UNNATURALLY null java.lang.RuntimeException: TESTING: Kill BEFORE store update: pid=112, state=RUNNABLE:MODIFY_TABLE_DESCRIPTOR_UPDATE, hasLock=true; InitializeStoreFileTrackerProcedure table=testRecoverWithRestoreAclFlag at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.kill(ProcedureExecutor.java:1779) ~[classes/:?] at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1723) ~[classes/:?] at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1414) ~[classes/:?] at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$1100(ProcedureExecutor.java:78) ~[classes/:?] at org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1981) ~[classes/:?] 2022-03-14T11:23:14,012 WARN [Time-limited test] procedure2.ProcedureTestingUtility(193): Set Kill before store update to: false
The CloneSnapshotProcedure is finished but then we get a InitializeStoreFileTrackerProcedure which messes up the test.
The InitializeStoreFileTrackerProcedure will be scheduled when rolling upgrade, where we do not have SFT set for a table. So typically it should not be schedule. Not sure how this could happen in the UT, need to dig more.
But anyway, when we clone a snapshot which was taken before we have SFT, it is possible the TableDescriptor does not have SFT implementation set, so we should set one for it.