SCALE: async no retry with broadcast_tx_async RPC call, "txn sent to RPC" response returned, query for txn status using either view-account-changes RPC endpoint or transaction-status

[anthony-near]

To be clear, this doesn't migrate from using the blocking broadcast request from near-rpc. (this is the endpoint that was being backfilled, because NEAT was sending requests this way). In the future, the relayer could also support the broadcast_tx_async , it would then have to long-poll to wait for the transaction outcome to update the balances and such in the relayer store. It is reasonably more work than the fix we have now though, but probably a good failover feature in the long term, if some issue like this happened again.

[anthony-near]

https://github.com/near/pagoda-relayer-rs-fastauth/pull/61/files

[anthony-near]

I don't think that the relayer polling 300x is a good long term solution under high load. There have been complaints in the past about the relayer response times being high, but the reason they are high is due to the relayer waiting for transaction finality from the RPC. Rather, the relayer can return that the txn has been sent async to the RPC. Fastauth can then say something like "your account is being created..." and then use view-account RPC endpoint to poll for account creation status. If you would like, I could add the view-account as another http endpoint for you to call on the relayer and the relayer would handle the RPC view-account query.

For transactions besides create account (could also use for create-account), we could use the view-account-changes RPC endpoint instead of polling in the same thread as send transaction on the relayer. A nice feature about this endpoint is that it allows for querying multiple account_ids in the same RPC call.

[anthony-near]

Create new /view-account-changes endpoint on the relayer that accepts multiple account_ids and returns the result

[anthony-near]

I think the problem of high latencies while waiting on the RPC to confirm transaction finality can be solved by decoupling the sending of the transaction to the RPC and the waiting for transaction finality. We can start by using the broadcast_tx_async RPC endpoint on the relayer to send the txn which immediately returns a transaction hash, which gets returned back to the signing service. We can then call either: a) /transaction-status endpoint on the relayer with parameters transaction hash and sender account id, which the relayer will use to call transaction-status RPC endpoint b) /view-account-changes RPC endpoint with parameters account_ids, which supports querying updates for multiple account_ids in a single view-account-changes RPC query

[anthony-near]

Create account transaction requires using a polling on relayer endpoint since it's linked to oauth token which can only be used once (no txn failure permissable). This would be for other transactions that go through relayer

[anthony-near]

Maybe change the RPC finality to doomslug or optimistic

[anthony-near]

implemented here: https://github.com/near/pagoda-relayer-rs/pull/65