HBASE-30346: Fix NPE in AbstractFSWAL WAL-roll debug logging aborting…

[mnpoonia]

… RegionServer

FSHLog#getPipeline() delegated directly to Hadoop's DFSOutputStream#getPipeline(), which can legitimately return null (streamer closed, or no block pipeline currently established between blocks). The debug logging added in HBASE-28775 replaced the null-tolerant Arrays.toString(...) with Arrays.stream(...), which throws NPE on null, turning a benign transient HDFS state into a RegionServer self-abort during WAL rolling -- even though the roll itself had already succeeded.

Normalize FSHLog#getPipeline() to never return null (an empty array instead), matching the contract AsyncFSWAL#getPipeline() already honors.

[mnpoonia]

Need help in triggering the workflow.
@virajjasani @Apache9 @apurtell FYI

[Apache9]

This only happens for FSHLog?

[mnpoonia]

This only happens for FSHLog?

Yes — this is FSHLog-only.

FSHLog#getPipeline() delegated directly to Hadoop's DFSOutputStream#getPipeline(), which can legitimately return null (streamer closed, or no block pipeline currently established) — that's the
crash site.

AsyncFSWAL#getPipeline() is unaffected:

DatanodeInfo[] getPipeline() {
  return output != null ? output.getPipeline() : new DatanodeInfo[0];
}

where output is one of:

• FanOutOneBlockAsyncDFSOutput#getPipeline() → returns locations, set once in the constructor and never nulled
• WrapperAsyncFSOutput#getPipeline() → always returns new DatanodeInfo[0]

Neither can return null, and AsyncFSWAL already null-guards the output reference itself. So only the sync WAL implementation (FSHLog) could propagate a null pipeline into the null-intolerant
Arrays.stream(...) call — AsyncFSWAL was never at risk.

[mnpoonia]

@Apache9 @virajjasani Can you help get this PR though. If needed i am happy to open PR for branch-3 and branch-2. I did check and the code was same but can open seperate PR if needed.