davsclaus opened a new pull request, #29020: URL: https://github.com/apache/camel/pull/29020
Fixes [CAMEL-26194](https://issues.apache.org/jira/browse/CAMEL-26194). ### 1. A body that does not convert to `byte[]` overwrote the znode with null `ZooKeeperUtils.getPayloadFromExchange` used the non-mandatory `ExchangeHelper.convertToType`, so a `Map`, a POJO or an `Integer` body became `null` and the producer silently wrote no data to the znode. Now a non-null body is converted with `getMandatoryBody(byte[].class)`, so such a body fails the exchange with an `InvalidPayloadException` and the znode keeps its data. A null body still stores no data (an explicit empty write). A `DELETE` no longer reads the body at all, so a `Map` body with a `DELETE` still works. ### 2. InOnly writes were fire-and-forget For an InOnly exchange the producer used the async ZooKeeper API, and the callbacks only logged. A write to a missing znode, a stale `CamelZooKeeperVersion` header, or a delete of a missing znode left the exchange successful. The `AsyncSetDataCallback` also logged a failed `setData` (other than `NONODE`) as "Stored data", and threw an NPE when the create of a missing node threw. Now InOnly uses the same synchronous operations as InOut and fails the exchange when the operation failed. An InOnly exchange keeps its message and body, as before. The async callbacks are removed. ### 3. `DELETE` of a missing znode with `create=true` created it `synchronouslyDelete` called `createNode` on `NONODE` when `create=true`. The create branch is removed: a delete of a missing znode now fails with `NoNodeException`, the same as without `create=true`. ### Same lines: `listChildren=true` hid a failed write or delete For InOut with `listChildren=true`, the result of the write or delete was replaced by the child listing without checking it, so a failed write returned the listing and no exception. The children are now listed only when the write or delete succeeded. ### 4. Without `repeat=true` the consumer emits only the initial data This is how the consumer has always worked. It is now documented, as the issue proposed: in the `repeat` option description and on the component page. The default is not changed. ### Tests New `ZooKeeperProducerTest` (13 tests) runs a ZooKeeper server in the test JVM, as `ZooKeeperConsumerSessionExpiryTest` does, so it needs no Docker. 10 of the 13 tests failed before the fix. The other 3 (text body stored, null body stores no data, listing after a successful write) guard the behaviour that is kept. The full module build with `-Psourcecheck` passed: 25 unit tests and 39 integration tests (ZooKeeper from test-infra). ### Docs and generated files - `zookeeper-component.adoc`: the `repeat` behaviour, the failure of a body that cannot be converted, the InOnly wait, and the delete of a missing znode. - `@BodyTypes` of the endpoint now describe the new producer behaviour. Regenerated the component JSON, the catalog copies, the endpoint DSL and the component DSL. - Upgrade guide 4.24: new `camel-zookeeper` section, since InOnly sends now wait and can fail, and a body that cannot be converted now fails. ### Not changed - The consumer default stays `repeat=false`: changing it would change what every existing route receives. - A null body still writes no data: ZooKeeper allows it, and it is the way to clear a znode. _Claude Code on behalf of Claus Ibsen (davsclaus)_ 🤖 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]
