[
https://issues.apache.org/jira/browse/CAMEL-26173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136866#comment-18136866
]
Claus Ibsen commented on CAMEL-26173:
-------------------------------------
PR: https://github.com/apache/camel/pull/29002
Fixed in the PR: 1 (atBlock, fromBlock and toBlock default to latest), 2
(ETH_GET_TRANSACTION_RECEIPT gives the TransactionReceipt or null; upgrade
guide entry), 3 (clear messages when the operation is missing; the consumer
also accepts the operation in lower case like the producer).
Not changed: 4 (UndeliverableException on stop). web3j registers Filter::cancel
as the Cancellable of the Flowable, and Filter.cancel() throws a
FilterException when eth_uninstallFilter fails. RxJava 2's
CancellableDisposable.dispose() catches it and sends it to
RxJavaPlugins.onError. Disposable.dispose() does not throw, so
Web3jConsumer.doStop cannot catch it. The only hook is the JVM-wide
RxJavaPlugins.setErrorHandler.
Options:
a) Leave it as is and ask web3j to log the failure in Filter.cancel() instead
of throwing (recommended; the filter expires on the node anyway).
b) Install a global RxJava error handler from camel-web3j when none is set,
which logs a FilterException at DEBUG and keeps the default for anything else.
This changes JVM-wide state that other libraries share.
c) Build the filter Flowables in Camel from web3j's LogFilter/BlockFilter with
our own Cancellable that catches the error. That means much more code to keep
in sync with web3j.
Question: is (a) fine, or do you want (b) or (c)?
_Claude Code on behalf of Claus Ibsen (davsclaus)_
> camel-web3j - ETH_GET_BALANCE and ETH_GET_BLOCK_BY_NUMBER fail with NPE
> without atBlock (documented default latest is null)
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26173
> URL: https://issues.apache.org/jira/browse/CAMEL-26173
> Project: Camel
> Issue Type: Bug
> Components: camel-web3j
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> Found while adding the catalog body types of web3j (CAMEL-24961, PR #28412).
> h4. 1. atBlock, fromBlock and toBlock are documented with default latest but
> are null
> In {{Web3jConfiguration}} (main 2a465aa4814c, lines 33-40) {{fromBlock}},
> {{toBlock}} and {{atBlock}} have {{defaultValue = "latest"}} but the fields
> are not initialized, and {{Web3jHelper.toDefaultBlockParameter}} (line 29)
> returns null for null. So {{ETH_GET_BALANCE}} ({{Web3jProducer}} line 258)
> and {{ETH_GET_BLOCK_BY_NUMBER}} (line 474) without {{atBlock}} fail every
> call with a NullPointerException "defaultBlockParameter is null". The
> consumer passes the same null {{fromBlock}}/{{toBlock}} to the log filter and
> the replay observables ({{Web3jConsumer}} lines 91-92, 137-138, 146-147; read
> in the code). Checked on 4.24.0-SNAPSHOT with a JDK HTTP server as the
> JSON-RPC node (the real {{HttpService}}).
> Proposed: initialize the three fields to {{"latest"}} as documented.
> h4. 2. ETH_GET_TRANSACTION_RECEIPT puts an Optional in the body
> {{Web3jProducer.ethGetTransactionReceipt}} (main 2a465aa4814c, line 564) sets
> the body to {{response.getTransactionReceipt()}}, an
> {{Optional<TransactionReceipt>}}, while the {{ETH_GET_TRANSACTION_BY_*}}
> operations unwrap the Optional to the {{Transaction}} or null (lines 497,
> 510, 524). Checked on 4.24.0-SNAPSHOT with the JSON-RPC node.
> Proposed: unwrap it the same way (the receipt or null), with a note in the
> upgrade guide.
> h4. 3. The default operation transaction is not valid for the consumer
> The {{operation}} option defaults to {{transaction}} ({{Web3jConfiguration}}
> lines 30-31). The producer does nothing for it, and a consumer with no
> {{operation}} fails at start with "Unsupported operation transaction"
> ({{Web3jConsumer}} line 153). Checked on 4.24.0-SNAPSHOT with the JSON-RPC
> node.
> Proposed: fail with a clear message that the consumer needs one of the
> observable operations (and that the producer needs an operation), or document
> that {{operation}} is required.
> h4. 4. Stopping a consumer reports an UndeliverableException when
> eth_uninstallFilter fails
> {{Web3jConsumer.doStop}} (main 2a465aa4814c, line 304) disposes the
> subscription; web3j then calls {{eth_uninstallFilter}}, and when the node
> answers with an error it goes to the RxJava global error handler as an
> {{UndeliverableException}} with a stack trace on the shutdown thread. Checked
> on 4.24.0-SNAPSHOT with the fake JSON-RPC node only.
> Proposed: handle the failure of the filter removal on stop (log it at DEBUG)
> so it does not reach the RxJava global error handler.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
