Provide guidelines for retrying transaction submission

[aborg-dev]

This is a tracking issue for work on guidelines on how to write a well-functioning client that reliably submits transactions to the RPC nodes.

We need to decide how transactions that are rejected due to overload (#8878) get retried in the clients (e.g. wallets, near.social frontend).

If we don’t agree on this with the clients and suddenly start dropping transactions in the pool the clients might:

• DDOS the RPC nodes retrying the same transaction
• End up in the invalid state, assuming that a transaction got accepted while it didn’t

Concretely, we should understand what the clients are doing today and see if it’s realistic to migrate them towards exponential backoff policy.

Clients that we should check/notify:

• Whatever near.social is using
• Near-api-js
• Rust clients (pagoda-relayer-rs, workspaces-rs)
• Near-api-py

Concrete steps

Beta Give feedback

1. Write down guidelines for a safe retry policy when submitting transactions
2. Advertise these guidelines through DevRel channels
3. Ensure that these guidelines are followed by the clients that submit the most transactions

[aborg-dev]

The next step here would be to chat with @DavidM-D about the NEAR client ecosystem and how they approach waiting for transactions/retrying failures.

[aborg-dev]

We had a good discussion with @bowenwang1996 about this and identified the following challenges to address:

• Long-polling connections to broadcast_tx might start to time out under congestion
• Clients of JSONRPC API will have to handle a new error code during transaction submission when Validator rejects the transaction due to running out of space in the transaction pool

For completeness, here is the whiteboard from the discussion:

[bowenwang1996]

Long-polling connections to broadcast_tx might start to time out under congestion

Minor correction: it is broadcast_tx_commit. broadcast_tx_async works differently. It does not wait for the transaction to finish before returning.

[aborg-dev]

I believe the work on congestion control partially covered this, so closing this issue.