It is really a good that this has already been fixed. Thanks for checking it!

Marking it as a dupe of HDFS-6094

Looks like HDFS-6094 fixed this in 2.4.0 by making NN learn StorageInfo from incremental block reports.

This happens when only NN restarts and an incremental block report is received after the node registration, but before adding the storage. I.e. queued incremental block report coming first before the first heartbeat. In this case, BlockInfoUnderConstruction#addReplicaIfNotPresent() is called from addStoredBlockUnderConstruction(), but the StorageInfo is null. Since the storage is not added yet, node.getStorageInfo(storageID) is null. As a result, the BlockInfoUnderConstruction will have one ReplicaUnderConstruction with its expectedLocation set to null. This is apparent from the log message from the processing of such an incremental block report.

WARN BlockStateChange: BLOCK* addStoredBlock: Redundant addStoredBlock request received for 
blk_1089713407_xxxxx{blockUCState=UNDER_CONSTRUCTION, primaryNodeIndex=-1, 
replicas=[ReplicaUnderConstruction[null|FINALIZED]]} on 1.2.3.4:1004 size 0

After this, fsck will fail with a NPE and the LeaseManager will also crash with a NPE.

Sorry, it was seen on a 2.3 cluster. I will verify wether we still have this bug in 2.4

It may have something to do with loading fsimage + edits and processing under-construction files. LeaseManager crashes one hour after NN start-up.

replicas.size() was non-zero and there was a corresponding ReplicaUnderConstruction, but its expectedLocation seemed to be null. This can happen if setExpectedStorageLocations() were called with array of nulls. This might happen if a last block with null locations is turned into a BlockInfoUnderConstruction. There might be other ways though.