Thanks, @Alan_G. Another thing that was brought up before is routes that issue expensive API calls. Double loading can deplete API credits faster and ends up consuming other resources on the server (memory, CPU parsing, etc.), which might cancel out the caching/speed benefits intended for the merchant.
Our workaround for that, and for creative/destructive admin links and subscription callbacks, is to make the initial handler redirect to another route, without the token, which the second request can’t follow. In our setup with the Shopify_app gem, this ends up loading a splash page, which then fetches the final destination and performs the action. So, what would normally be 1 request becomes 4.
It makes development and debugging more complex, and the server works less efficiently. I wish there was a way to opt out, using perhaps a meta tag.
I noticed the two requests to the app happening recently too. I don’t have clear evidence, but I think this could be why I’m seeing ‘failed to register webhook’ errors when the app is first installed.
My guess is two requests are made to app.tsx in close proximity, so the registerWebhooks call in the afterAuth hook is being triggered twice, and the 2nd one returns errors because its attempting to register webhooks that are already registered.
Doesn’t really cause any issues but just thought I’d add to the discussion.
I really appreciate your patience on this - really happy to try to get to the bottom of it for sure. I do need a bit more data to properly investigate (especially the jump from 2 to 3 requests),
It would be super helpful if anyone could share:
A HAR file showing the 3-request behaviour (just one example would be super helpful!)
Any plain-text X-Request-IDs from failed request response headers
Your app ID (feel free to DM me if you’d prefer to keep it private)
Without those specifics there, I’m a bit limited in terms of what we can do to help. Thanks again for bearing with me on this - more than happy to get this looked into.
Thanks @Taj_Bowness - I received the DM on my end here - I’ll open up a DM with you on this forum here just for ease of reference as well to follow up - speak with you soon!
Hey folks - we’ve rolled back the changes on our end that led to this issue popping up.
Could you let us know if it persists? My understanding is that this shouldn’t happen going forward, but if it does just ping me here and I’ll take a look. We do have new methods of handling app load performance in the pipeline in the near future, so I just wanted to mention that as well. I can’t guarantee a timeframe for that specifically, but any updates would be on the changelog here: Recent changes to Shopify’s platform
Hey @Thor_Stenbaek - thanks for following up on this. You shouldn’t need to update anything on your end - could you let me know if you’re still seeing the issue pop up and if so, share a shop ID and the app ID for your app? Happy to dig into this further with you if you’re still seeing it pop up.
As I understand if you are using Shopify Appbridge CDN there is no need to do anything.
If you are still using package, first check the request to see if it has the issue as reported in this thread.
It might just be a coincidence, but we were getting complaints from some merchants that the app was asking them to reinstall randomly, from May 31st to around June 11.
We haven’t heard about that issue since, despite not changing anything, so whatever was done could have fixed that, too.
No worries @flavio-b and all - please feel free to ping me here if you do see this issue pop up again. Happy to investigate further if needed, as always!
