av9ash/GitBugs huggingface dataset:
Bug: RefreshPeerProcedure should be resilient to replication endpoint failures
Status: Open | Priority: Major | Resolution: 
Created: 28/Jun/23 06:24
Affects Version/s: 2.4.14

UpdatePeerConfigProcedure gets stuck when we see some failures in RefreshPeerProcedure. The only way to move forward is either by restarting active master or bypassing the stuck procedure.

 

For instance,
{code:java}
2023-06-26 17:22:08,375 WARN  [,queue=24,port=61000] replication.RefreshPeerProcedure - Refresh peer peer0 for UPDATE_CONFIG on {host},{port},1687053857180 failed
java.lang.NullPointerException via {host},{port},1687053857180:java.lang.NullPointerException: 
    at org.apache.hadoop.hbase.procedure2.RemoteProcedureException.fromProto(RemoteProcedureException.java:123)
    at org.apache.hadoop.hbase.master.MasterRpcServices.lambda$reportProcedureDone$4(MasterRpcServices.java:2406)
    at java.util.ArrayList.forEach(ArrayList.java:1259)
    at java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1082)
    at org.apache.hadoop.hbase.master.MasterRpcServices.reportProcedureDone(MasterRpcServices.java:2401)
    at org.apache.hadoop.hbase.shaded.protobuf.generated.RegionServerStatusProtos$RegionServerStatusService$2.callBlockingMethod(RegionServerStatusProtos.java:16296)
    at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:385)
    at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:132)
    at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:369)
    at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:349)
Caused by: java.lang.NullPointerException: 
    at xyz(Abc.java:89)     <========= replication endpoint failure example
    at xyz(Abc.java:79)     <========= replication endpoint failure example
    at org.apache.hadoop.hbase.replication.ReplicationPeerImpl.lambda$setPeerConfig$0(ReplicationPeerImpl.java:63)
    at java.util.ArrayList.forEach(ArrayList.java:1259)
    at org.apache.hadoop.hbase.replication.ReplicationPeerImpl.setPeerConfig(ReplicationPeerImpl.java:63)
    at org.apache.hadoop.hbase.replication.regionserver.PeerProcedureHandlerImpl.updatePeerConfig(PeerProcedureHandlerImpl.java:131)
    at org.apache.hadoop.hbase.replication.regionserver.RefreshPeerCallable.call(RefreshPeerCallable.java:70)
    at org.apache.hadoop.hbase.replication.regionserver.RefreshPeerCallable.call(RefreshPeerCallable.java:35)
    at org.apache.hadoop.hbase.regionserver.handler.RSProcedureHandler.process(RSProcedureHandler.java:49)
    at org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:98)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:750) {code}
RefreshPeerProcedure should support reporting this failure and rollback of the parent procedure.
Bug: Report memstore on-heap and off-heap size as jmx metrics
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 25/May/23 21:28

Currently we only report "memStoreSize" metric in sub=RegionServer bean. I've noticed a big discrepancy between this metric and the RS UI's "Memstore On-Heap Size". It seems like "memStoreSize" is the overall data size, while the on-heap size is coming from our heap estimation which includes POJO heap overhead, etc.

I have a regionserver with only 750mb of "memStoreSize", but the on-heap size is over 1gb.  This is non-trivial for estimating overall heap size necessary for a regionserver. Since we have the data, let's report it.
Bug: Leak in ServerCall.setResponse
Status: Open | Priority: Major | Resolution: 
Created: 26/Jun/23 14:03

I'm stress testing the RegionServer for TLS and noticing the following leak:

 
{code:java}
ERROR org.apache.hbase.thirdparty.io.netty.util.ResourceLeakDetector: LEAK: RefCnt.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records:
Created at:
        org.apache.hadoop.hbase.nio.RefCnt.<init>(RefCnt.java:59)
        org.apache.hadoop.hbase.nio.SingleByteBuff.<init>(SingleByteBuff.java:55)
        org.apache.hadoop.hbase.io.ByteBuffAllocator.allocateOneBuffer(ByteBuffAllocator.java:280)
        org.apache.hadoop.hbase.io.ByteBufferListOutputStream.allocateNewBuffer(ByteBufferListOutputStream.java:61)
        org.apache.hadoop.hbase.io.ByteBufferListOutputStream.checkSizeAndGrow(ByteBufferListOutputStream.java:90)
        org.apache.hadoop.hbase.io.ByteBufferOutputStream.writeInt(ByteBufferOutputStream.java:154)
        org.apache.hadoop.hbase.util.ByteBufferUtils.putInt(ByteBufferUtils.java:429)
        org.apache.hadoop.hbase.codec.KeyValueCodec$KeyValueEncoder.write(KeyValueCodec.java:61)
        org.apache.hadoop.hbase.ipc.CellBlockBuilder.encodeCellsTo(CellBlockBuilder.java:187)
        org.apache.hadoop.hbase.ipc.CellBlockBuilder.buildCellBlockStream(CellBlockBuilder.java:223)
        org.apache.hadoop.hbase.ipc.ServerCall.setResponse(ServerCall.java:256)
        org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:160)
        org.apache.hadoop.hbase.ipc.CallRunnerWithContext.run(CallRunnerWithContext.java:74)
        org.apache.hadoop.hbase.ipc.RpcHandler.run(RpcHandler.java:102)
        org.apache.hadoop.hbase.ipc.RpcHandler.run(RpcHandler.java:82) {code}
 

One thing to note is that due to my stress test Netty is throwing OutOfDirectMemoryError, which extends OutOfMemoryError. I see we have handling for that in CallRunner, not sure if it's related.
Bug: NPE in StoreFileReader.passesGeneralRowPrefixBloomFilter()
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 15/Jun/23 14:16

When executing itbll, we encountered the following NPE exception：
{code:java}
java.lang.NullPointerException
        at org.apache.hadoop.hbase.regionserver.StoreFileReader.passesGeneralRowPrefixBloomFilter(StoreFileReader.java:352)
        at org.apache.hadoop.hbase.regionserver.StoreFileReader.passesBloomFilter(StoreFileReader.java:265)
        at org.apache.hadoop.hbase.regionserver.StoreFileScanner.shouldUseScanner(StoreFileScanner.java:483)
        at org.apache.hadoop.hbase.regionserver.StoreScanner.selectScannersFrom(StoreScanner.java:467)
        at org.apache.hadoop.hbase.regionserver.StoreScanner.<init>(StoreScanner.java:320)
        at org.apache.hadoop.hbase.regionserver.StoreScanner.<init>(StoreScanner.java:289)
        at org.apache.hadoop.hbase.regionserver.compactions.Compactor.createScanner(Compactor.java:544)
        at org.apache.hadoop.hbase.regionserver.compactions.Compactor$1.createScanner(Compactor.java:269)
        at org.apache.hadoop.hbase.regionserver.compactions.Compactor.compact(Compactor.java:358)
        at org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:64)
        at org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:122)
        at org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1176)
        at org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2407)
        at org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.doCompaction(CompactSplit.java:667)
        at org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.run(CompactSplit.java:716)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:750)
{code}
Bug: New async admin api to invoke coproc on multiple servers
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Jun/23 04:58

We can execute regionserver coproc on a given regionserver using:
{code:java}
<S, R> CompletableFuture<R> coprocessorService(Function<RpcChannel, S> stubMaker,
  ServiceCaller<S, R> callable, ServerName serverName); {code}
We should also provide an api at admin layer that can invoke the given coproc endpoint on multiple servers, to help execute the given function in parallel across the entire cluster.
Bug: Meta replication stuck forever if wal it's still reading gets rolled and deleted
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 17/May/23 14:44
Affects Version/s: 2.4.16

This affects branch-2 based releases only (in master, HBASE-26416 refactored region replication to not rely on the replication framework anymore).

Per the original [meta region replicas design|https://docs.google.com/document/d/1jJWVc-idHhhgL4KDRpjMsQJKCl_NRaCLGiH3Wqwd3O8/edit], we use most of the replication framework for communicating changes in the primary replica back to the secondary ones, but we skip storing the queue state in ZK. In the event of a region replication crash, we should let the related replication source thread be interrupted, so that 
RegionReplicaReplicationEndpoint would set a new source from the scratch and make sure to update the secondary replicas.
 
We have run into a situation in one of our customers' cluster where the region replica source faced a long lag (probably because the RSes hosting the secondary replicas were busy and slower in processing the region replication entries), so that the current wal got rolled and eventually deleted whilst the replication source reader was still referring it. In such cases, ReplicationSourceReader only sees the IOException and keeps retrying the read indefinitely, but since the file is now gone, it will just get stuck there forever. In the particular case of FNFE (which I believe would only happen for region replication), we should just raise an exception and let RegionReplicaReplicationEndpoint handle it to reset the region replication source.
Bug: Midkey metadata in root index block would always be ignored by BlockIndexReader.readMultiLevelIndexRoot
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 17/Jun/23 03:10
Affects Version/s: 2.4.17

After HBASE-27053， checksum is removed from the {{HFileBlock}} {{ByteBuff}}  in {{FSReaderImpl.readBlockDataInternal}}  once the checksum is verified, so {{HFileBlock.buf}} does not include checksum, but for {{BlockIndexReader.readMultiLevelIndexRoot}}, after read root index entries , it still subtracts the checksum to check if the midkey metadat exists,  the midkey metadata would always be ignored: 

{code:java}
public void readMultiLevelIndexRoot(HFileBlock blk, final int numEntries) throws IOException {
      DataInputStream in = readRootIndex(blk, numEntries);
      // after reading the root index the checksum bytes have to
      // be subtracted to know if the mid key exists.
      int checkSumBytes = blk.totalChecksumBytes();
      if ((in.available() - checkSumBytes) < MID_KEY_METADATA_SIZE) {
        // No mid-key metadata available.
        return;
      }
      midLeafBlockOffset = in.readLong();
      midLeafBlockOnDiskSize = in.readInt();
      midKeyEntry = in.readInt();
 }
{code}
Bug: Remove duplicate code for NettyHBaseSaslRpcServerHandler and make the sentByte metrics more accurate
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Jun/23 08:17
Affects Version/s: 2.6.0

{{NettyHBaseSaslRpcServerHandler.doResponse}}  and  {{ServerRpcConnection.doRawSaslReply}} are very similar, I think we could replace {{NettyHBaseSaslRpcServerHandler.doResponse}}  with {{ServerRpcConnection.doRawSaslReply}}： 

{code:java}
private void doResponse(ChannelHandlerContext ctx, SaslStatus status, Writable rv,
    String errorClass, String error) throws IOException {
    // In my testing, have noticed that sasl messages are usually
    // in the ballpark of 100-200. That's why the initial capacity is 256.
    ByteBuf resp = ctx.alloc().buffer(256);
    try (ByteBufOutputStream out = new ByteBufOutputStream(resp)) {
      out.writeInt(status.state); // write status
      if (status == SaslStatus.SUCCESS) {
        rv.write(out);
      } else {
        WritableUtils.writeString(out, errorClass);
        WritableUtils.writeString(out, error);
      }
    }
    NettyFutureUtils.safeWriteAndFlush(ctx, resp);
  }
{code}


{code:java}
protected final void doRawSaslReply(SaslStatus status, Writable rv, String errorClass,
    String error) throws IOException {
    BufferChain bc;
    // In my testing, have noticed that sasl messages are usually
    // in the ballpark of 100-200. That's why the initial capacity is 256.
    try (ByteBufferOutputStream saslResponse = new ByteBufferOutputStream(256);
      DataOutputStream out = new DataOutputStream(saslResponse)) {
      out.writeInt(status.state); // write status
      if (status == SaslStatus.SUCCESS) {
        rv.write(out);
      } else {
        WritableUtils.writeString(out, errorClass);
        WritableUtils.writeString(out, error);
      }
      bc = new BufferChain(saslResponse.getByteBuffer());
    }
    doRespond(() -> bc);
  }
{code}

At the same time, {{NettyHBaseSaslRpcServerHandler.doResponse}}  sends ByteBuf directly , not the unified {{RpcResponse}} , so  it would not handled by the logic in  {{NettyRpcServerResponseEncoder.write}}, which would update the {{MetricsHBaseServer.sentBytes}}.  Using   {{ServerRpcConnection.doRawSaslReply}} uniformly would make the {{MetricsHBaseServer.sentBytes}} more accurate.
Bug: create-release is broken by recent gitbox changes
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 27/May/23 00:38

The error looks like:
{noformat}
...
GIT_BRANCH [branch-2.5]: 
-:1: parser error : Space required after the Public Identifier
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
{noformat}
but is misleading. What is going on is create-release tries to retrieve the top level POM from the specified branch using a gitbox URL but gitbox is returning an HTML redirect, which is not what is expected.
{noformat}
++ read -r -p 'GIT_BRANCH [branch-2.5]: ' REPLY
GIT_BRANCH [branch-2.5]: 
++ local RETVAL=branch-2.5
++ '[' -z branch-2.5 ']'
++ echo branch-2.5
+ GIT_BRANCH=branch-2.5
+ export GIT_BRANCH
+ local version
++ curl -s 'https://gitbox.apache.org/repos/asf?p=hbase.git;a=blob_plain;f=pom.xml;hb=refs/heads/branch-2.5'
++ parse_version
++ xmllint --xpath '//*[local-name()='\''project'\'']/*[local-name()='\''version'\'']/text()' -
-:1: parser error : Space required after the Public Identifier
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
{noformat}
{noformat}
$ curl -s 'https://gitbox.apache.org/repos/asf?p=hbase.git;a=blob_plain;f=pom.xml;hb=refs/heads/branch-2.5'
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://raw.githubusercontent.com/apache/hbase/refs/heads/branch-2.5/pom.xml">here</a>.</p>
</body></html>
{noformat}
The solution is to retrieve content using github URLs (via raw.githubusercontent.com) instead of gitbox URLs.
Bug: Missing reference guide for 2.5.x stable
Status: Open | Priority: Major | Resolution: 
Created: 15/Jun/23 08:51
Affects Version/s: 2.5.5

On [https://hbase.apache.org/,] the "Documentation and API" dropdown does not provide links for the "Ref Guide" and "Reference Guide (PDF) for the current stable 2.5.x version.

The expected location for this ([https://hbase.apache.org/2.5/book.html)] gives a 404. This means users cannot view the docs for the current 2.5.x stable version, since [https://hbase.apache.org/] shows the docs of master (3.0.x).
Bug: Finish 3.0.0-alpha-4 release
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 07/Jun/23 14:06

# Release the artifacts on repository.apache.org (/)
# Move the binaries from dist-dev to dist-release (/)
# Add xml to download page(via HBASE-27913) (/)
# Push tag 3.0.0-alpha-4RC0 as tag rel/3.0.0-alpha-4 (/)
# Release 3.0.0-alpha-4 on JIRA https://issues.apache.org/jira/projects/HBASE/versions/12351845 (/)
# Add release data on https://reporter.apache.org/addrelease.html?hbase (/)
# Send announcement email (/)
Bug: HBase is not starting due to Jersey library conflicts with javax.ws.rs.api jar
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 28/Apr/23 04:29
Affects Version/s: 3.0.0-alpha-3

With some recent Atlas changes for supporting HTTP based hook support, HBase is not starting because of conflicts between jersey jars and rs-api jar.

This Jira is to exclude the javax.ws.rs-api.jar from the HBase classpath.

HBase uses shaded jersey jars and hence does not need to use this jar directly. However, it still adds this jar to the CLASSPATH while starting the server. Atlas on the other hand is using a non-shaded version of javax.ws.rs-api jar which causes this conflict and causes the hbase server fail while initializing atlas co-processor.

Since hbase is using shaded jersey jar and not using this jar directly, it should be removed from the bundle as it may cause similar conflicts with other client applications potentially using it.
Bug: log4j configuration file not worked
Status: Resolved | Priority: Major | Resolution: Not A Bug
Created: 06/Jun/23 07:43

HBase sets the HBASE_ROOT_LOGGER variable in many startup scripts, and finally places this variable in the startup parameters in the bin/hbase script, "-Dhbase.root.logger=${HBASE_ROOT_LOGGER:-INFO,console}". This is really strange as it overrides the log4j configuration, which is not beneficial for users who are not familiar with HBase because they cannot enable debug by modifying the log4j configuration.
Bug: [HBOSS] Open file fails with NumberFormatException for S3AFileSystem
Status: In Progress | Priority: Major | Resolution: 
Created: 01/Jun/23 15:26
Affects Version/s: 1.0.0-alpha2

In HADOOP-18724 it is shown that the new overloaded setters for double and float can cause type mismatch and end up setting s3a integer values to floats to see what breaks.

The wrapper in HBASE-26483 should mimic the hadoop fix and for all double/float values passed in, cast to log and set as integers only. Nothing has ever used the float/double values, so this isn't a regression
Bug: Make HBCK be able to report unknown servers
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 13/Apr/23 19:23

Currently hbck is not reporting unknown servers it would be helpful to report those as inconsistencies so that directly hbck2 schedulerecoveries  option can be used to recover on unknown servers otherwise the taking the action for inconsistencies reported due to unknown servers may corrupt if not done properly.
Bug: org.apache.hadoop.hbase.exceptions.TimeoutIOException: Failed to get sync result after 300000 ms for txid=895, WAL system stuck?
Status: Open | Priority: Major | Resolution: 
Created: 31/May/23 12:37
Affects Version/s: 2.2.2

2023-04-15 06:41:23,278 ERROR [regionserver/bdpprd03:16020-longCompactions-0] regionserver.CompactSplit: Compaction failed region=OLAP:XS_USER_BEHAVIOR_RISK,325001600010,1681250348046.3823c66e8cb8bca3bd9eb1757d3c2a1b., storeName=info, priority=9, startTime=1681511184093
*{color:#de350b}org.apache.hadoop.hbase.exceptions.TimeoutIOException: Failed to get sync result after 300000 ms for txid=895, WAL system stuck?{color}*
        at org.apache.hadoop.hbase.regionserver.wal.SyncFuture.get(SyncFuture.java:145)
        at org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL.blockOnSync(AbstractFSWAL.java:731)
        at org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.sync(AsyncFSWAL.java:611)
        at org.apache.hadoop.hbase.regionserver.wal.WALUtil.doFullAppendTransaction(WALUtil.java:158)
        at org.apache.hadoop.hbase.regionserver.wal.WALUtil.writeMarker(WALUtil.java:136)
        at org.apache.hadoop.hbase.regionserver.wal.WALUtil.writeCompactionMarker(WALUtil.java:70)
        at org.apache.hadoop.hbase.regionserver.HStore.writeCompactionWalRecord(HStore.java:1512)
        at org.apache.hadoop.hbase.regionserver.HStore.doCompaction(HStore.java:1441)
        at org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1428)
        at org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2235)
        at org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.doCompaction(CompactSplit.java:616)
        at org.apache.hadoop.hbase.regionserver.CompactSplit$CompactionRunner.run(CompactSplit.java:658)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Bug: Possible NPE while getting cluster status from master
Status: Open | Priority: Major | Resolution: 
Created: 25/May/23 03:56

 
{noformat}
2023-05-23 13:31:33,840 ERROR [RpcServer.default.FPBQ.Fifo.handler=395,queue=35,port=16000] ipc.RpcServer: Unexpected throwable object 
java.lang.NullPointerException
    at org.apache.hadoop.hbase.shaded.protobuf.generated.ClusterStatusProtos$ServerTask$Builder.setStatus(ClusterStatusProtos.java:14120)
    at org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.toServerTask(ProtobufUtil.java:3565)
    at org.apache.hadoop.hbase.ClusterMetricsBuilder.lambda$toClusterStatus$4(ClusterMetricsBuilder.java:80)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1384)
    at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
    at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566)
    at org.apache.hadoop.hbase.ClusterMetricsBuilder.toClusterStatus(ClusterMetricsBuilder.java:80)
    at org.apache.hadoop.hbase.master.MasterRpcServices.getClusterStatus(MasterRpcServices.java:980)
    at org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
    at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:387)
    at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:124)
    at org.apache.hadoop.hbase.ipc.RpcHandler.run(RpcHandler.java:102)
    at org.apache.hadoop.hbase.ipc.RpcHandler.run(RpcHandler.java:82)
{noformat}
Bug: Avoid always reinit the decompressor in the hot read path
Status: Open | Priority: Major | Resolution: 
Created: 24/May/23 03:07
Affects Version/s: 2.5.4

When seting "hbase.block.data.cachecompressed=true", the cached blocks are decompressed when reading. But we are using pooled decompressors here, which means the decompressor configs should be refreshed as a prepare job before each decompressing, see the line here 

[https://github.com/apache/hbase/blob/22526a6339afa230679bcf08fa1c917b04cdac6d/hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/HFileBlockDefaultDecodingContext.java#L99]

I have pointed out the lock of Configuration.get problem in HBASE-27672, it should be avoid when reiniting in the hot read path either. 

!image-2023-05-24-11-06-48-569.png|width=668,height=286!
Bug: Should fast-fail if unmatched column family exists when using ImportTsv
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 05/May/23 14:03
Affects Version/s: 2.4.13

Executing cmd as following:
{code:java}
//code
hbase org.apache.hadoop.hbase.mapreduce.ImportTsv -Dimporttsv.separator=, -Dimporttsv.columns=HBASE_ROW_KEY,temp01_error01:first_name,temp01_error02:last_name test_hbase hdfs:///tmp/hbase_data.csv {code}
If We specify a error column family(it does not exists), this operation would not fail until MR job is executed

It is better to fast-fail before MR is submitted if we specify a error column family