chore: support RPC consistency mechanism

[nedsalk]

Note

Merges into

• chore: upgrade fuel-core to 0.42.0 #3749

• Closes Review and Add Special Headers for Optimistic Concurrency Control #3443

Release notes

In this release, we:

• added support for required_fuel_block_height to fix RPC consistency issues

Summary

flowchart TD
    Initialize[init: currentBlockHeight = 0] --> prepareRequest[prepare request]
    
    prepareRequest --> isRequestBlockSensitive[is request block height sensitive]

    isRequestBlockSensitive --> isSensitive[yes]
    isRequestBlockSensitive --> isNotSensitive[no]

    isSensitive --> addBlockHeight[inform required block height]

    addBlockHeight --> sendRequest[send request]

    isNotSensitive --> sendRequest[send request]


    sendRequest --> response[response has block height error?]

    response --> blockHeightError(yes)
    response --> noBlockHeightError(no)

    blockHeightError --> shouldRetry(should retry?)

    shouldRetry --> retry(yes)
    shouldRetry --> noRetry(no)

    retry --> wait(wait)
    wait --> sendRequest

    noRetry --> throwError(throw error)

    noBlockHeightError --> extractBlockHeight(extract block height from response)

    extractBlockHeight --> isHigher

    isHigher[is value higher than current?]

    isHigher --> higher[yes]
    isHigher --> nonHigher[no]

    higher --> updateBlockHeight[set new value]
    updateBlockHeight --> End[end]
    
    nonHigher --> End

Loading

Checklist

• All changes are covered by tests (or not applicable)
• All changes are documented (or not applicable)
• I reviewed the entire PR myself (preferably, on GH UI)
• I described all Breaking Changes (or there's none)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
fuels-template	❌ Failed (Inspect)			Mar 10, 2025 1:07pm
ts-docs	❌ Failed (Inspect)			Mar 10, 2025 1:07pm
ts-docs-api	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 10, 2025 1:07pm

[nedsalk]

For some reason, the Provider static instance isn't the same between the one available in the tests that's initialized in launchTestNode and the one that's used in our runCommand test utility; perhaps it has something to do with comandeer. I verified this by assigning a static id = getRandomB256() to the Provider and logging it in the constructor. A different string gets logged after calling runCommand.

The problem is that both of them live simultaneously across all tests in this file and what would happen is the first test would finish successfully, kill the node and clear the currentBlockHeight cache of its static instance... but it wouldn't clear the other Provider's currentBlockHeight which would remain high (e.g. 15). In the next test, runDeploy would try to deploy to a new fuel-core node initialized for that test, but that node would have a block height of 0 and it would stall as the required_fuel_block_height isn't reached. Our custom awaiting mechanism isn't working here because we're running the node with --poa-instant true so we're only creating blocks when submitting transactions - but we can't submit a transaction because the block height is too low.

In the end, I opted to rewrite the tests to not use the same 4000 port across all tests, which resolves us of the problem. We might only have flakiness in the very rare case that the OS assigns the same port to launchTestNode in two tests in this file, which would reproduce the same problem. Because runCommand is our test utility, it won't affect the users. For users who want to run all their launchTestNode tests on the same port as was done in this test, this change will suffice.