I’m seeing this error on my POS extension occasionally, doesn’t really give me much information to go off, wondering if the Shopify team could give some more context.
I know Apollo is a GQL client, I’ve used it in other projects but I’m not using it here so I assume it is being used by Shopify POS but I’m not sure why it would be used for just a normal fetch request?
Here is an example of the stacktrace from POS running on an iPad, again not much to go off
ApolloError · Network request failed
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:13048209 ApolloError
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:21512827 error
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:6975537 notifySubscription
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:13046116 error
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:19192974 anonymous
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:6975537 notifySubscription
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:13046116 error
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:12963583 anonymous
(native) forEach
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:17226827 error
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:6975537 notifySubscription
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:13046116 error
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:21092181 anonymous
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:17194166 step
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:19183937 anonymous
address at /private/var/containers/Bundle/Application/9C740D16-891B-4D92-80EB-BD1E91880BD3/POSNext.app/main.jsbundle:1:19183715 fulfilled
address at InternalBytecode.js:1:1274 tryCallOne
address at InternalBytecode.js:1:4865 anonymous
Hey @simon_b - good to see you, thanks for flagging this. That stack is coming from the POS app side, but we’d need a bit more detail to tell whether this is a connectivity issue, a direct API/authenticated fetch issue, or something in the POS fetch layer.
Could you share:
Shopify POS app version and iPadOS version
Extension API version and target
Whether the failing fetch is to your own backend or shopify:admin/api/graphql.json
Whether it happens on specific devices/networks, or across all of them
A rough timestamp/timezone from one recent failure
If you can reproduce it again, please also send a POS bug report from the affected device right after the error happens:
In the Shopify POS app, tap ... > Support.
Tap Report a bug.
Add a short description of the issue and include my username, Alan_G.
Tap Send.
Once we have those logs and the details above, I can definitely take a closer look on our end!
Hi @Alan_G thanks heaps for getting back to me, I’ll see what further info I can gather now.
This seems to happen intermittently across a number of devices. I’m just curious how I could handle it really, as currently I’m just showing a generic error message when it occurs.
Hey @simon_b - thanks for digging up the extra details, super helpful.
The accounts.shopify.com/oauth/token bit is the main clue here. I checked telemetry logs on our end around the timestamps you shared, and I think I can see your matching POS-side network/token fetch failures, including cases where POS was trying to reach that token endpoint.
So from what I can see right now, this looks more like a transient POS connectivity/auth-token fetch issue than Apollo being used directly by your extension code. The Apollo part is likely just how that POS-side request failure is bubbling up.
That said, we’d still need the local POS/device logs from an affected device right after the issue happens to confirm that definitively and see if it’s a wider issue on our end. If you’re able to reproduce it again, just send a POS bug report from within the POS app.
For handling it in your extension, I’d treat this as recoverable where possible: check POS connectivity before making backend calls, catch rejected fetches, show a connection-specific message in your extension UI, and give users a retry path. App authentication and direct API access still need network access, so these can fail before your backend receives anything.
On the API version question, 2025-07 is still within the supported window, but I’d plan to move toward the latest supported POS API version when you can.
Hi @Alan_G thanks for investigating this one for us. So you’re thinking that this is a case of the device losing connectivity part way through the request or something like that?
I don’t actually know how to reproduce this one to be honest. This is something we see via our bug reporting on the POS extension from devices out in the wild. So I’m not sure I will be able to get you logs but we’ll see.
I will add an exception handler specifically for this and show a connectivity related message.
Hey again @simon_b - exactly, that’s roughly how I’d interpret it, with one small thing I’d add: it may not always mean the device fully lost connectivity, but it does look like POS couldn’t complete the network/auth-token request at that moment. Since that token fetch can happen before your backend request is actually sent, you may not see a matching hit in your own backend logs.
Your plan sounds right here, though, treating this as recoverable, catch that specific network failure path, show a connectivity-focused message, and give the user a retry option. If you can, I’d also capture the UTC timestamp, POS app version, device model/OS, and current connectivity state when it happens so that we can keep digging into this if it keeps recurring.
If you do manage to get a POS bug report from an affected device right after it happens, send that through and I can take another look on our end, happy to help!
Thanks @Alan_G I made a change to the extension to handle these errors, automatically attempting a retry when they occur but re-raising them if it fails again.
So far I’ve not seen this error on our monitoring software since making that change.
