bug(subscriber): When shutdown process occurs, the stop method of the subscriber fails.

[AlfredoG87]

Description

Seems that when the shutdown app is called the subscriber might crash.

This is at least the case when the shutdown is called from a plugin on the init process.

Steps to Reproduce

1. Make the Historic Plugin Shutdown the App due to a SEVERE error like a corrupted zip file. (see issue:
2. Watch the logs.

Additional context

java.util.zip.ZipException: zip END header not found
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.findEND(ZipFileSystem.java:1320)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.initCEN(ZipFileSystem.java:1541)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.<init>(ZipFileSystem.java:179)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getZipFileSystem(ZipFileSystemProvider.java:125)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:120)
        at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:528)
        at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:475)
        at org.hiero.block.node.blocks.files.historic@0.21.1/org.hiero.block.node.blocks.files.historic.ZipBlockArchive.minStoredBlockNumber(ZipBlockArchive.java:161)
        at org.hiero.block.node.blocks.files.historic@0.21.1/org.hiero.block.node.blocks.files.historic.BlockFileHistoricPlugin.init(BlockFileHistoricPlugin.java:108)
        at org.hiero.block.node.app@0.21.1/org.hiero.block.node.app.BlockNodeApp.<init>(BlockNodeApp.java:178)
        at org.hiero.block.node.app@0.21.1/org.hiero.block.node.app.BlockNodeApp.main(BlockNodeApp.java:314)

2025-11-03 19:19:37.332+0000 INFO    [org.hiero.block.node.app.BlockNodeApp shutdown] Shutting down, reason: Error reading directory: /opt/hiero/block-node/data/historic/000/000/000/006/38 because zip END header not found, class: org.hiero.block.node.blocks.files.histor
ic.ZipBlockArchive
2025-11-03 19:19:37.833+0000 INFO    [org.hiero.block.node.app.BlockNodeApp shutdown] Stopping plugin: BlockMessagingFacilityImpl
2025-11-03 19:19:37.834+0000 INFO    [org.hiero.block.node.app.BlockNodeApp shutdown] Stopping plugin: HistoricalBlockFacilityImpl
2025-11-03 19:19:37.834+0000 INFO    [org.hiero.block.node.app.BlockNodeApp shutdown] Stopping plugin: BlockFileRecentPlugin
2025-11-03 19:19:37.834+0000 INFO    [org.hiero.block.node.app.BlockNodeApp shutdown] Stopping plugin: BlockFileHistoricPlugin
2025-11-03 19:19:37.835+0000 INFO    [org.hiero.block.node.app.BlockNodeApp shutdown] Stopping plugin: S3ArchivePlugin
2025-11-03 19:19:37.835+0000 INFO    [org.hiero.block.node.app.BlockNodeApp shutdown] Stopping plugin: SubscriberServicePlugin
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "org.hiero.block.node.stream.subscriber.SubscriberServicePlugin$SubscribeBlockStreamHandler.stop()" because "this.clientHandler" is null
        at org.hiero.block.node.stream.subscriber@0.21.1/org.hiero.block.node.stream.subscriber.SubscriberServicePlugin.stop(SubscriberServicePlugin.java:74)
        at org.hiero.block.node.app@0.21.1/org.hiero.block.node.app.BlockNodeApp.shutdown(BlockNodeApp.java:298)
        at org.hiero.block.node.blocks.files.historic@0.21.1/org.hiero.block.node.blocks.files.historic.ZipBlockArchive.minStoredBlockNumber(ZipBlockArchive.java:175)
        at org.hiero.block.node.blocks.files.historic@0.21.1/org.hiero.block.node.blocks.files.historic.BlockFileHistoricPlugin.init(BlockFileHistoricPlugin.java:108)
        at org.hiero.block.node.app@0.21.1/org.hiero.block.node.app.BlockNodeApp.<init>(BlockNodeApp.java:178)
        at org.hiero.block.node.app@0.21.1/org.hiero.block.node.app.BlockNodeApp.main(BlockNodeApp.java:314).

[ata-nas]

What we are observing here is a lifecycle issue.

The block node has the following lifecycle:

1. Main method instantiates the block node app.
   1. Configs, contexts and base classes get instantiated (like server, metrics etc.).
   2. The constructor loads (SPI) all plugins (noargs constructor is called) and calls init on all of them.
2. The main method proceeds to call start on the instantiated block node app.
   1. All base classes are started (server, metrics etc.).
   2. All loaded plugins get called the start method
3. The block node is operational.

Sometimes we initialize plugin fields in the init method, sometimes in the start method because we need the different lifecycle points in order to ensure other things are present. This means that it is possible that sometimes we have invalid state until the plugin is fully operational. In the stacktrace above we can see that a failure happens during the block node app instantiation. When that happens, all plugins are called the stop method. In the case of the subscriber, however, the clientHandler thereof is not instantiated until the start method is called. This obviously will not happen if we have a failure during the construction of the block node app. Hence this illegal state produces the NPE.

We should take heed and make sure that we either have or check for proper state in the stop methods of plugins.

We must review all places and introduce safer code.

[ata-nas]

@Nana-EC pre-planned for 0.69.0 B / 0.24.0 as we discussed. We can chose to defer as well. Not assigned priority, phase and feature group.