Fix silent exception swallow in LocalFsBlobStore.prepare() leaving stormClusterState null

[jnioche]

Problem

In LocalFsBlobStore.prepare(), the call to ClusterUtils.mkStormClusterState() is wrapped in a try/catch that silently swallows any exception via e.printStackTrace():

try {
    this.stormClusterState = ClusterUtils.mkStormClusterState(conf, new ClusterStateContext(DaemonType.NIMBUS, conf));
} catch (Exception e) {
    e.printStackTrace();  // stormClusterState remains null
}

If this call fails — for example because ZooKeeper is unreachable at startup — stormClusterState stays null and prepare() returns successfully. The failure is only visible as a stack trace on stderr, which is easily lost in production log aggregation pipelines.

This creates a time-bomb: the blob store appears to initialise correctly, but every subsequent operation that touches the cluster state will throw a NullPointerException with no indication of the root cause:

• startSyncBlobs() — this.stormClusterState.blobstore(...)
• setupBlobstore() — state.activeKeys() (where state = stormClusterState)
• blobSync() — state.blobstore(...)

The NPE stack trace points into blob store internals, making it very hard to diagnose that the real problem was a ZooKeeper connection failure that happened earlier during prepare().

Fix

Rethrow the exception as a RuntimeException so that prepare() itself fails with a clear message and the original cause preserved:

try {
    this.stormClusterState = ClusterUtils.mkStormClusterState(conf, new ClusterStateContext(DaemonType.NIMBUS, conf));
} catch (Exception e) {
    throw new RuntimeException("Failed to initialize cluster state for LocalFsBlobStore", e);
}

This matches the pattern already used a few lines above in the same method for FileBlobStoreImpl initialisation, making the two failure modes consistent:

try {
    fbs = new FileBlobStoreImpl(baseDir, conf);
} catch (IOException e) {
    throw new RuntimeException(e);  // existing pattern
}

Nimbus now fails fast at startup with a meaningful error rather than entering a degraded state where blob operations crash with confusing NPEs.

[rzo1]

@jnioche Looks like it needs an adjustment in

classname: org.apache.storm.localizer.AsyncLocalizerTest / testname: testKeyNotFoundException
org.opentest4j.AssertionFailedError: Unexpected exception type thrown, expected: <org.apache.storm.generated.KeyNotFoundException> but was: <java.lang.RuntimeException>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:158)
	at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:68)
	at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:35)
	at org.junit.jupiter.api.Assertions.assertThrows(Assertions.java:3223)
	at org.apache.storm.localizer.AsyncLocalizerTest.testKeyNotFoundException(AsyncLocalizerTest.java:795)
Caused by: java.lang.RuntimeException: Failed to initialize cluster state for LocalFsBlobStore
	at org.apache.storm.blobstore.LocalFsBlobStore.prepare(LocalFsBlobStore.java:113)
	at org.apache.storm.blobstore.LocalFsBlobStore.prepare(LocalFsBlobStore.java:97)
	at org.apache.storm.localizer.AsyncLocalizerTest.lambda$testKeyNotFoundException$3(AsyncLocalizerTest.java:803)
	at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:54)
	... 3 more
Caused by: java.lang.RuntimeException: org.apache.storm.shade.org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /storm

[rzo1]

see CI

[jnioche]

Sorry, had rushed this one a bit. About to push a fix

Root cause of the test failures: Both tests were accidentally relying on the silent exception swallow. They called prepare() without any ZooKeeper in the config, which caused mkStormClusterState to throw — but the old
e.printStackTrace() swallowed it and let the tests proceed with stormClusterState = null. The tests happened to pass because neither test's assertions touched cluster state.