fix: calculated transaction record query cost instead of querying operator balance

[quiet-node]

Description:
This PR introduces a solution to calculate the transaction record query based on the exchange rate instead of querying the operator's balance. This fix eliminates the need for the two balance queries in each metrics capture request, which could cause significant timeouts when the callData size is large.

Fixes #2846
Related issue: #2808
Related issue: #2847

Notes for reviewer:

Checklist

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

[github-actions]

Tests

       3 files     207 suites   16s ⏱️
1 046 tests 1 045 ✔️ 1 💤 0 ❌
1 058 runs  1 057 ✔️ 1 💤 0 ❌

Results for commit e5cab22.

♻️ This comment has been updated with latest results.

[github-actions]

Acceptance Tests

  21 files  261 suites   31m 10s ⏱️
613 tests 589 ✔️ 4 💤 20 ❌
795 runs  769 ✔️ 4 💤 22 ❌

Results for commit 7c78887.

♻️ This comment has been updated with latest results.

[victor-yanev]

Instead of extending the timeout from 45 seconds to 90 seconds to address the flakiness, I think we should focus on the fact that this transaction used to complete in less than 45 seconds, and now it’s taking twice as long.

The delay is especially evident when the relay executes multiple file appends and has to retry operator balance queries during hbar limiter metrics capture. To improve user experience and avoid unnecessary slowdowns, I suggest we handle these metrics asynchronously and address the actual problem which we have - that this transaction no longer executes in the time frame it used to.

[quiet-node]

Instead of extending the timeout from 45 seconds to 90 seconds to address the flakiness, I think we should focus on the fact that this transaction used to complete in less than 45 seconds, and now it’s taking twice as long.

The delay is especially evident when the relay executes multiple file appends and has to retry operator balance queries during hbar limiter metrics capture. To improve user experience and avoid unnecessary slowdowns, I suggest we handle these metrics asynchronously and address the actual problem which we have - that this transaction no longer executes in the time frame it used to.

Hey @victor-yanev, thanks for the comment! I also noticed that the main issue behind this timeout problem stems from the TransactionService class, as I mentioned in the "notes for reviewer" section. That’s why I labeled it as a "temporary" solution to help unblock the PRs for now. But yes, I definitely agree with you and appreciate the great suggestion—I’ll look into making the account balance queries asynchronous to improve the situation.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.81%. Comparing base (af09470) to head (e5cab22).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2848      +/-   ##
==========================================
- Coverage   82.66%   81.81%   -0.86%     
==========================================
  Files          49       46       -3     
  Lines        3554     3403     -151     
  Branches      751      718      -33     
==========================================
- Hits         2938     2784     -154     
- Misses        370      391      +21     
+ Partials      246      228      -18     

Flag	Coverage Δ
relay	81.67% <100.00%> (-0.18%)	⬇️
server	81.19% <ø> (ø)
ws-server	97.87% <ø> (ø)

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

Files	Coverage Δ
packages/relay/src/lib/constants.ts	90.90% <ø> (-9.10%)	⬇️
.../services/transactionService/transactionService.ts	87.50% <100.00%> (+0.65%)	⬆️

... and 14 files with indirect coverage changes