feat: enabled fast return on eth_sendRawTransaction

[quiet-node]

Description:

The eth_sendRawTransaction endpoint currently faces timeouts from various sources, including server, network, and client settings. For large callData, it uses Hedera File Service (HFS) to create and append file transactions, increasing latency and degrading user experience.

This PR introduces a new conceptual feature design for eth_sendRawTransaction, enabling the API to return the transaction hash immediately upon passing prechecks. All subsequent processing (e.g., broadcasting to the network, handling file transactions, polling the mirror node, tracking HBAR consumption, etc.) is handled asynchronously in the background.

The primary impact of this feature is a significant reduction in end-to-end client wait times while ensuring backend integrity remains intact.

Important Note for Clients:

With the transaction hash returned instantly, clients must monitor the transaction status using this hash (e.g., via eth_getTransactionReceipt or monitoring confirmations).

If a request encounters internal errors (e.g., exceeding maxChunkSize, HBAR limits, SDK errors), these will no longer appear in the response. Instead, a transaction hash is returned, and eth_getTransactionReceipt may return null indefinitely. That said, it remains the responsibility of the users to handle such cases appropriately.

Fixes #3270

Related issue(s):

Additional aspects and considerations of the feature are highlighted in the ongoing discussion in #3202. Please feel free to share your insights in the thread if you have any.

Notes for reviewer:

TL;DR; The primary change in this PR is a refactor, mainly within eth.ts. The remaining work involves updating tests to align with the new immediate return logic. Most efforts are directed toward adding polling logic to verify the validity of transactions before proceeding to the next instruction.

• The feature is designed for backward compatibility, allowing it to be toggled on or off while ensuring the end-to-end flow remains consistent.
• A new global configuration, USE_ASYNC_TX_PROCESSING, acts as the feature flag for this functionality.
• The EthImpl.sendRawTransaction method has been refactored to extract transaction processing logic into a new function, sendRawTransactionTxProcessor(). When USE_ASYNC_TX_PROCESSING is enabled, sendRawTransactionTxProcessor() is called without await, allowing transaction processing to run asynchronously in the background. If the flag is disabled, the function is awaited, maintaining the original synchronous flow.
• The remainder of the work focuses on updating tests to accommodate the new feature.

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[github-actions]

Test Results

 22 files  +  3  309 suites  +64   1h 1m 14s ⏱️ + 31m 40s
606 tests  -   5  597 ✅  -   6  4 💤 ±0  5 ❌ +1 
819 runs  +187  809 ✅ +185  4 💤 ±0  6 ❌ +2 

For more details on these failures, see this check.

Results for commit d274e6b. ± Comparison against base commit 7accf1f.

This pull request removes 9 and adds 4 tests. Note that renamed tests count towards both.

"before all" hook for "should individually update amountSpents of different spending plans" ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch2 Multiple users with different tiers "before all" hook for "should individually update amountSpents of different spending plans"
"before each" hook for "Should eventually exhaust the hbar limit for EXTENDED user and still allow another EXTENDED user to make calls" ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch2 Preconfigured Tiers EXTENDED Tier "before each" hook for "Should eventually exhaust the hbar limit for EXTENDED user and still allow another EXTENDED user to make calls"
"before each" hook for "Should increase the amount spent of the spending plan by the transaction cost" ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch2 Preconfigured Tiers PRIVILEGED Tier "before each" hook for "Should increase the amount spent of the spending plan by the transaction cost"
@release fail "eth_getTransactionReceipt" on precheck with wrong nonce error when sending a tx with a higher nonce ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Transaction related RPC Calls Prechecks @release fail "eth_getTransactionReceipt" on precheck with wrong nonce error when sending a tx with a higher nonce
Should eventually exhaust the total HBAR limits after many large contract deployments by different tiered users ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch2 Multiple users with different tiers Should eventually exhaust the total HBAR limits after many large contract deployments by different tiered users
should create a BASIC spending plan for a new user and use the same plan on second transaction and different plan on third transaction from another user ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch1 BASIC Tier should create a BASIC spending plan for a new user and use the same plan on second transaction and different plan on third transaction from another user
should eventually exhaust the hbar limit for a BASIC user after multiple deployments of large contracts ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch1 BASIC Tier should eventually exhaust the hbar limit for a BASIC user after multiple deployments of large contracts
should execute "eth_sendRawTransaction" and deploy a contract with more than max transaction fee ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-1 RPC Server Acceptance Tests RPC Server Acceptance Tests Transaction related RPC Calls should execute "eth_sendRawTransaction" and deploy a contract with more than max transaction fee
should individually update amountSpents of different spending plans ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch2 Multiple users with different tiers should individually update amountSpents of different spending plans

Should eventually exhaust the total HBAR limits after many large contract deployments ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch1 Multiple users with different tiers Should eventually exhaust the total HBAR limits after many large contract deployments
should create a BASIC spending plan for a new user and use the same plan on second transaction and different plan on third transaction from another user ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch2 BASIC Tier should create a BASIC spending plan for a new user and use the same plan on second transaction and different plan on third transaction from another user
should eventually exhaust the hbar limit for a BASIC user after multiple deployments of large contracts ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch2 BASIC Tier should eventually exhaust the hbar limit for a BASIC user after multiple deployments of large contracts
should individually update amountSpents of different spending plans ‑ RPC Server Acceptance Tests Acceptance tests @hbarlimiter HBAR Limiter Acceptance Tests HBAR Rate Limit Tests HBAR Rate Limit For Different Spending Plan Tiers @hbarlimiter-batch1 Multiple users with different tiers should individually update amountSpents of different spending plans

♻️ This comment has been updated with latest results.

[quiet-node]

Left some notes and questions for reviewers.

[natanasow]

LG, several tests are failing due to an undefined variable. Let's fix them before the final approvals.

[sonarcloud]

Quality Gate failed

Failed conditions
5.7% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[quiet-node]

LG, several tests are failing due to an undefined variable. Let's fix them before the final approvals.

@natanasow Thanks for the good catch! Missed that during rebasing! Updated!

[natanasow]

LGTM. Thanks for the great work!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.92%. Comparing base (7accf1f) to head (d274e6b).
Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3273      +/-   ##
==========================================
+ Coverage   77.82%   77.92%   +0.09%     
==========================================
  Files          66       66              
  Lines        4474     4476       +2     
  Branches     1005     1004       -1     
==========================================
+ Hits         3482     3488       +6     
+ Misses        617      615       -2     
+ Partials      375      373       -2     

Flag	Coverage Δ
config-service	98.14% <ø> (ø)
relay	78.67% <100.00%> (+0.12%)	⬆️
server	83.28% <ø> (ø)
ws-server	36.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ckages/config-service/src/services/globalConfig.ts	100.00% <ø> (ø)
packages/relay/src/lib/eth.ts	71.28% <100.00%> (+0.21%)	⬆️
packages/relay/src/utils.ts	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes