allthingssecurity opened a new pull request, #28037: URL: https://github.com/apache/camel/pull/28037
# Description [CAMEL-25730](https://issues.apache.org/jira/browse/CAMEL-25730) `Web3jConsumer` subscribed once, in `doStart`, to a web3j `Flowable`. A `Flowable` that signals an error is over, and the consumer never subscribed again: one exchange with the exception was routed, then the route stayed started and received nothing more. In web3j 5.0.0, `blockFlowable`, `transactionFlowable` and `pendingTransactionFlowable` make a request to the node for each item inside a `flatMap` (for example `ethGetBlockByHash(hash, full).flowable()`), so one failed request (connection reset, node restart, timeout) ends `BLOCK_OBSERVABLE`, `TRANSACTION_OBSERVABLE` and `PENDING_TRANSACTION_OBSERVABLE` for good. A node that cannot be reached when the route starts does the same for every operation. Change (in `Web3jConsumer`): - after a live subscription ended with an error, the consumer subscribes again every 15 seconds until it succeeds, on a scheduled executor created in `doStart` and shut down in `doStop`; - the first error is routed as before and logged once at WARN without a stack trace; the attempts and their failures are logged at DEBUG until an item is received again, which is logged once at INFO; - a subscription made while the consumer stops (the executor shutdown does not wait for a running attempt) is disposed; - `REPLAY_BLOCKS_OBSERVABLE`, `REPLAY_TRANSACTIONS_OBSERVABLE` and an `ETH_LOG_OBSERVABLE` with `fromBlock` set to a block number are not subscribed again, as that would route the same blocks or logs again. What users can notice: the consumer keeps receiving after the node is back. A new subscription starts at the latest block, so the blocks between the error and the new subscription are not routed. Upgrade guide (4.24): a note under `camel-web3j`. No new option: the delay is a constant, with a package-private setter used by the tests. Tests: - New `Web3jConsumerResubscribeTest` (6 tests, mocked `Web3j`, no node). `blockSubscriptionEndedByAFailedRequestIsSubscribedAgain`, `failuresWhileSubscribingAgainAreRoutedOnce` and `logFilterFromTheLatestBlockIsSubscribedAgain` fail without the change: the tests set a 10 ms delay through the package-private setter, so they were run on unmodified main as a copy without the setter call and with a 25 s wait (`Expected: <2> but was: <1>`, `<1>`/`<0>`, `<1>`/`<0>`); the same copy passes with the change and the default 15 s delay. `replayOfARangeIsNotSubscribedAgain` and `logFilterFromAGivenBlockIsNotSubscribedAgain` pass with and without the change; they guard what must not be subscribed again. `subscriptionMadeWhileTheConsumerStopsIsDisposed` stops the route while a resubscription is in a slow request; it fails when the dispose after such a subscription is removed. - With the change the camel-web3j tests pass: 138 run, 0 failures, 0 errors, 67 skipped (the integration tests that need a node). Not covered: the blocks of the gap are not fetched; a log filter from `safe` or `finalized` is not subscribed again; when web3j's own reinstall of a filter the node forgot fails, web3j stops polling without an error, which the consumer cannot see. What was not run: the full root build; no test against an Ethereum node (web3j 5.0.0 read with javap). # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25730](https://issues.apache.org/jira/browse/CAMEL-25730). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-web3j, including the formatter and import-sort plugins. No option or generated file changed. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 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]
