anza-xyz / solana-pay

A new standard for decentralized payments.
https://solanapay.com
Apache License 2.0
1.28k stars 447 forks source link

Add more robust retry logic to Point of Sale app #56 #205

Closed lastemp closed 1 year ago

lastemp commented 1 year ago

This change adds two functions "findReferenceMultipleNodes" and "validateTransferMultipleNodes" from two new typescript files "validateTransferMultipleNodes.ts" and "findReferenceMultipleNodes.ts". These functions can be executed from Point of Sale app or any other application that interacts with Solana-pay.

The overall aim is to execute "findReference" and "validateTransfer" against multiple nodes to guarantee robustness.

This solves the issue "Add more robust retry logic to Point of Sale app #56"

vercel[bot] commented 1 year ago

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

Name Status Preview Comments Updated (UTC)
solana-pay ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 13, 2023 3:15pm
solana-pay-docs ❌ Failed (Inspect) May 13, 2023 3:15pm
mcintyre94 commented 1 year ago

Hey, thanks for contributing this! Since #56 was opened there's been some work on a rewrite of web3js which allows much more flexibility at the connection level. 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 us to keep behaviour like this outside of the Solana Pay library, and available to any code built on web3js.

I don't want to add code to the core SDK that tries to address this - we want to keep this core unopinionated and flexible. The new web3js looks like the best solution so far.

On the issue there was discussion of building a connection pooling library which could be used with this SDK or any other web3js code, and I think that's another potential solution. But I think this new web3js version is the most promising approach at the moment.

I'm going to close this for now, and will add a comment to #56 about this potential future solution. I know that this doesn't fix the issue in the immediate term, but we really don't want to add code that's quite this opinionated to the core SDK.

Thanks again for contributing, and let me know if you have any other questions! :)