Description
All four MirrorNodeClientImpl transaction query methods in the MicroProfile module use /api/v1/tokens instead of /api/v1/transactions, causing them to return token listings instead of transaction data. Additionally, enum parameters are serialized incorrectly:
queryTransactionsByAccountAndType passes the Java enum name (e.g. ACCOUNT_CREATE) instead of the mirror-node protocol string (CRYPTOCREATEACCOUNT)
queryTransactionsByAccountAndResult and queryTransactionsByAccountAndModification rely on toString() instead of name()
Even after correcting the endpoint, the JSON response parser (MirrorNodeJsonConverterImpl) crashes on live mirror-node transaction responses because:
charged_tx_fee, amount, and serial_number are returned as JSON numbers, but the parser calls getString() + Long.parseLong()
bytes, entity_id, and node can be JSON null, but the parser calls getString() directly (throws ClassCastException)
parent_consensus_timestamp null check uses .get(...).asJsonObject() == null, which never works in Jakarta JSON-P — should use jsonObject.isNull(key)
jsonArrayToStream throws on empty arrays, but an empty result set is valid
The equivalent Spring module works correctly for all of these cases.
Steps to reproduce
- Call any MicroProfile transaction query method, e.g.
TransactionRepository.findByAccount(AccountId.fromString(0.0.98))
- Observe: returns token data (wrong endpoint), or if endpoint is manually corrected, crashes with a parsing exception on the JSON response
Evidence
git show HEAD:...MirrorNodeClientImpl.java confirms the original code uses /api/v1/tokens in all four transaction methods
- Live Hedera mainnet mirror-node confirms
/api/v1/tokens?account.id=0.0.98 returns token data, while /api/v1/transactions?account.id=0.0.98 returns transaction data
- Mirror-node rejects
transactiontype=ACCOUNT_CREATE but accepts transactiontype=CRYPTOCREATEACCOUNT
Expected behavior
Transaction query methods should hit /api/v1/transactions, serialize enum parameters using the mirror-node protocol values, and parse JSON responses without crashing on numeric fields, null values, or empty arrays.
Description
All four
MirrorNodeClientImpltransaction query methods in the MicroProfile module use/api/v1/tokensinstead of/api/v1/transactions, causing them to return token listings instead of transaction data. Additionally, enum parameters are serialized incorrectly:queryTransactionsByAccountAndTypepasses the Java enum name (e.g.ACCOUNT_CREATE) instead of the mirror-node protocol string (CRYPTOCREATEACCOUNT)queryTransactionsByAccountAndResultandqueryTransactionsByAccountAndModificationrely ontoString()instead ofname()Even after correcting the endpoint, the JSON response parser (
MirrorNodeJsonConverterImpl) crashes on live mirror-node transaction responses because:charged_tx_fee,amount, andserial_numberare returned as JSON numbers, but the parser callsgetString()+Long.parseLong()bytes,entity_id, andnodecan be JSON null, but the parser callsgetString()directly (throwsClassCastException)parent_consensus_timestampnull check uses.get(...).asJsonObject() == null, which never works in Jakarta JSON-P — should usejsonObject.isNull(key)jsonArrayToStreamthrows on empty arrays, but an empty result set is validThe equivalent Spring module works correctly for all of these cases.
Steps to reproduce
TransactionRepository.findByAccount(AccountId.fromString(0.0.98))Evidence
git show HEAD:...MirrorNodeClientImpl.javaconfirms the original code uses/api/v1/tokensin all four transaction methods/api/v1/tokens?account.id=0.0.98returns token data, while/api/v1/transactions?account.id=0.0.98returns transaction datatransactiontype=ACCOUNT_CREATEbut acceptstransactiontype=CRYPTOCREATEACCOUNTExpected behavior
Transaction query methods should hit
/api/v1/transactions, serialize enum parameters using the mirror-node protocol values, and parse JSON responses without crashing on numeric fields, null values, or empty arrays.