rzo1 opened a new pull request, #9159: URL: https://github.com/apache/storm/pull/9159
Fixes #9157. **Depends on #9094.** This branch is stacked on it, because `topology.tuple.deserialization.strict.enable` only exists there. Only the last commit (6088ef9) belongs to this PR. I'll rebase onto master and mark it ready once #9094 is merged. ## Problem In strict mode, `DeserializingConnectionCallback.recv` rethrows the decode failure, and it reaches `StormServerHandler.exceptionCaught`. That method calls `Utils.handleUncaughtException` with `IOException` as the only allowed exception, and the check walks the cause chain. `ZstdUtils.decompress` and `KryoTupleDeserializer.deserializeTuple` both wrap an `IOException`, so a corrupt or oversized compressed frame closed the connection and discarded the batch, and the worker kept running. ## Change - In strict mode, `DeserializingConnectionCallback` wraps the failure in a new `FatalDeserializationException`, keeping the original as the cause. - `StormServerHandler` does not apply the `IOException` exemption when a `FatalDeserializationException` is in the chain, so every strict-mode failure terminates the worker. Genuine connection `IOException`s are handled as before. - Default (non-strict) mode is unchanged. - The `Config` javadoc, `docs/Serialization.md` and `docs/Metrics.md` no longer describe the IOException case as an exception to strict mode. `deserializationFailures` is still not incremented on the strict path, since the worker exits. ## Tests - `DeserializingConnectionCallbackTest`: the strict-mode tests expect `FatalDeserializationException` with the original cause, plus a new strict-mode test for a corrupt zstd frame. - New `StormServerHandlerTest`: a plain IOException-wrapping failure is swallowed, and one wrapped in `FatalDeserializationException` is not. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
