[todo] Add more robust retry logic to Point of Sale app

[jordaaash]

The point of sale app should probably be more robust against RPC or network errors (either from Solana or the WiFi).

[0xPratik]

Hey @jordansexton Can you please elaborate more on this issue. I would like to work on it. Thanks

[jordaaash]

Yeah, for sure. The goal is to increase the robustness of the app to connection issues.

We use a single RPC endpoint to find transactions in a loop until it's found. However, Phantom uses a different RPC by default (I think they use Triton) and then have some backup RPCs they use.

If our RPC node doesn't see the transaction that Phantom has sent yet, this causes latency to the user waiting for their transaction to confirm. It could be advantageous to poll several RPC nodes at once, from different RPC providers.

Because we use the same connection to validate the transaction, we will want to reuse whichever connection the transaction was found using (since it's possible it was seen by one node and not another). It's also possible that we should try to validate the transaction over several connections too.

We would probably want all the connections to race to find and validate the transaction, so the merchant and customer sees their transaction confirmed as fast as possible.

Additionally, it would be nice to have something that pinged a known good server to test the internet / WiFi connection from the PoS, so that we could indicate if there's an issue. This could be a separate PR, and should maybe be done before the more complicated RPC changes.

[jordaaash]

After spiking this out, it may be worth considering if more robust connection management could be encapsulated as a small library, which we could then use here. I could see many apps having use for something like this.

[nickbalestra]

Hey @jordansexton! I had a quick look into the codebase to see if I could help with this issue :) Set aside the small PR I've reference as an idea on how we could to make sure we are online. Here some thoughts:

I see that the connection is set through the ConnectionProvider from '@solana/wallet-adapter-react'. And I guess that is what you mentioned with We use a single RPC endpoint. I like the idea of a small library that could handle multiple endpoints/connections! Take this just as an early sketch/idea:

<ConnectionPoolProvider endPoints={[DEVNET_ENDPOINT, ...]}>...
// within the Provider we instantiate a pool through a small library, something like
const connectionPool = new ConnectionPool({endPoints}); 

// ...and somewhere within a nested component: 
const connectionPool = useConnectionPool();
const [signature, connection] = await connectionPool.run(findTransactionSignature, reference, undefined, 'confirmed');

// ...we might want to add support for keeping track of the latest active connection within the pool as well
const activeConnection = connectionPool.getActiveConnection();
activeConnection === connection // true

I am sure I am missing a lot of context here so would love to hear all your inputs, feedback and ideas on how to move forward with this.

[mcintyre94]

My current thinking on the RPC aspect of this is that the experimental web3js rewrite probably provides the best and most flexible solution here.

For example, Steven Luscher has tweeted an example of using this to round-robin requests to multiple RPC endpoints: https://twitter.com/steveluscher/status/1650794822687653888?s=20. This should allow writing a transport that eg races promises to multiple endpoints, or uses fallback RPCs, or any other behaviour that makes sense.

I'm working on contributing the endpoints required by this library to that rewrite. And once it's stable and has everything we need we'll update to use it, making this flexibility available.

[lastemp]

@mcintyre94 Thanks so much for feedback, this is really appreciated.

[thisissamridh]

Is this issue Closed or still open