discoverReaders gets stuck after failing to connect to an internet reader

[nprail]

Summary

If you attempt to connect to an internet reader but the connection fails, discoverReaders gets stuck. The completion callback is never called and all other API calls start erroring with the SDK busy error (e.g. Could not execute discoverReaders because the SDK is busy with another command: discoverReaders.). Even if you try to run cancelDiscoverReaders, the cancel callback completes but the issue does not get resolved and the discoverReaders completion callback still doesn't complete.

Code to reproduce

The Connect to a reader example should be enough to reproduce this. Once the reader has been discovered, turn it off and then attempt to connect to it. You shouldn't ever see "discoverReaders succeeded" logged.

iOS version

15.1

Installation method

CocoaPods

SDK version

2.4.0

Other information

This issue seems somewhat similar but it was resolved years ago: #29

[jil-stripe]

Thanks for reporting, @nprail. We'll look into this and try to make the experience better here.

[nprail]

@jil-stripe thanks! We have run into this SDK busy error in a lot of places. It is quite the pain to work around. But this is definitely one area where there's a bug that prevents us from working around it.

[jil-stripe]

Hm - sorry to hear that you're running into this error a lot. Do you have other examples where it's particularly painful, so I can dig in deeper?

[nprail]

@jil-stripe One of the biggest areas where we have problems with the busy SDK error is updating the reader display. We found that if we call setReaderDisplay or clearReaderDisplay too many times quickly, most of the calls fail and the reader's display becomes out of sync with our POS. We ended up working around it by creating a queue of calls for updating the display which mostly solved the issue. But we still hit edge cases from time to time. For example, there is a scenario where we are calling retrievePaymentIntent while the end user can still make changes to the cart, which triggers a call to setReaderDisplay.

Our app is Capacitor based and we use the capacitor-stripe-terminal plugin. On the web and Android versions, we do not run into any of these issues.

[bric-stripe]

👋 closing out old issues but also wanted to comment on:

One of the biggest areas where we have problems with the busy SDK error is updating the reader display. We found that if we call setReaderDisplay or clearReaderDisplay too many times quickly, most of the calls fail and the reader's display becomes out of sync with our POS

We're aware of the pain point here with BUSY and the difference between Android and iOS SDKs and do plan to address it, along with a few other big parity issues, but no timelines to provide.