There seems to be some very recent change that’s causing a critical issue on our production application.
On some page loads, fetch calls are hanging doing nothing, and clicking buttons that invoking modals also do nothing. This is affecting critical onboarding flows where users are required to select a billing plan before they can access the application.
Refreshing the page seems to resolve the issue.
The reason I’m inclined to believe this is an app bridge issue, is that I’ve tried much older builds (~3 week old commit) of our app where it was definitely working and it’s still broken in those older commits. Surely it hasn’t been broken that whole time otherwise we would have heard about it.
I’m continuing to investigate this issue on my end and will add information. Hopefully this is just something on our end that we can fix.
4 Likes
I think I’ve identified the cause. If you try to set the location via window.location.href = “<App url>”, app bridge doesn’t seem to initialize correctly on that subsequent page load.
A potential solution lies here. I modified the app bridge script to bypass the CDN checks, then updated the shopify-reload handling to fetch the ID token, inject it as a param, then navigate to that instead of fetching the HTML content and replacing the document’s contents.
I don’t know if this is the solution I will use, for obvious reasons, but maybe it helps shed some light as to what’s going on.
1 Like
I’m stumped with this and cannot find an acceptable solution. Here’s some relevant info that I hope helps.
- Our back-end uses Rails + shopify_app gem
- This occurs when loading a page that redirects to /patch_shopify_id_token
- It has to do with how App Bridge handles that
shopify-reload param. With that patch I suggested above, there is no issue. However I’m hesitant to do something in production that Shopify explicitly states not to do.
- We noticed the problem around ~3pm PST.
This affects our critical onboarding and billing flows. Just to ensure it’s not a dev thing, I created a brand new non-partner store, and the issue persisted. We did not push a new change which would result in this, I tested a 3 month old commit and the issue is still present. Really hope someone can shed some light on this.
Hey Kyle - DMing you for details!
@Liam-Shopify We are experiencing what appears to be the same issue in our app. It started around ~4pm EST yesterday and is still occurring today.
Suddenly, all of our declarative navigation through internal links(including both Polaris s-link/s-button components and legacy <a> elements)
as well as our imperative navigation via open() calls
stopped working as expected. The pages are hanging and we started getting sessionToken bounces.
If we directly enter the specific URL, it loads without any issues. The problem only occurs when attempting to navigate to those URLs programmatically or through internal links.
Any help would be greatly appreciated.
@Kyle_K_Helium @Joshua_Lucas Can you please check if this is mitigated?
1 Like
Issue appears mitigated on our end - working with @Kyle_K_Helium
@Henry_Tao Just checked on our end and everything is working now. Thank you for your quick resolution!
Yep – confirmed that the issue seems to be resolved. Thank you 
In lieu of venting my obvious frustration, I really hope this incident encourages the app bridge team to adjust their versioning practices. I’m not going to argue “go back to versioning”, but it would be nice if we could get some visibility into app bridge code updates.
Working through the night on an issue I don’t know if I actually have control over sucked. I’m not able to compare the current app bridge version vs. the previous, I don’t actually even know when app bridge updates so it’s hard to tell if something is on our end or otherwise.
Bugs are the nature of humans building software. This won’t be the last time something like this happens. So maybe next time, can we at least debug this easier? Help us help you.
Edit: I guess I should also ask: What was the issue? Was it even related to app bridge?
6 Likes
