Bug: Double Requests from Shopify Admin iFrame Issue

[jason_engage]

I just discovered an issue that has been affecting my apps since mid march.

I isolated the issue to merchants entering our embedded apps using BROWSERS (iframe). Shopify sends 2 identical requests to the server - the timestamps in the requests themselves are IDENTICAL. Paste of nginx records below.

1. This does NOT happen when entering from the mobile app (which means there is something that its doing differently than the iframe version),

2. And it does not happen when entering directly on my development server (which means my server isn’t likely to be the issue).

These facts point to some potential issue with the iFrame setup in the Shopify web admin. After the initial entry, it does not duplicate any subsequent calls.

Can anyone else confirm this in their server logs? Is there some configuration somewhere I don’t have setup correctly maybe?

Only respond to this post if you work for Shopify or have manually verified your server logs when entering your app via Shopify Mobile App vs. Shopify Web Admin. Thank you

2025/04/14 16:38:58 [error] 2984549#2984549: *3957981 FastCGI sent in stderr: “PHP message: ENTRY” while reading response header from upstream, client: 187.246.19.27, server: seoking.engageify.com, request: “GET /dashboard?embedded=1&hmac=68cbafe554486f8aede07d89dc52937c6341195a6456a592f4819ae1bdddc408&host=YWRtaW4uc2hvcGlmeS5jb20vc3RvcmUvbW90by1yYWQtY29t&id_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczpcL1wvbW90by1yYWQtY29tLm15c2hvcGlmeS5jb21cL2FkbWluIiwiZGVzdCI6Imh0dHBzOlwvXC9tb3RvLXJhZC1jb20ubXlzaG9waWZ5LmNvbSIsImF1ZCI6ImY0YTJhOWQyMjM3ZDZmOWIyODllOWU0MjdmNmUzZDgyIiwic3ViIjoiODk0ODM1NDI3NDgiLCJleHAiOjE3NDQ2NDg3OTcsIm5iZiI6MTc0NDY0ODczNywiaWF0IjoxNzQ0NjQ4NzM3LCJqdGkiOiI1YWU4YjMyZi04NjdiLTRmZDQtOTEwZC03ZmJmNjI4ZDY4OTUiLCJzaWQiOiI1NTM4MGQ2OC02NGQ3LTRhN2QtYWEwNy0xOTk5Y2ZmZGI0NjciLCJzaWciOiJjNzMzZGY3OWNkOWRmNDVlNDIxZmU1YmZjYjg2OTQwYmFiMzMwYjJiZDVhOTQyZGFlOTFiYWZkNGM2MzU1MmM4In0.lc2XWhKP6rs_ztCb1rydA4dYuOrUwnrV__AdL3sN3bk&locale=es-MX&session=bf5ade7bbb94c405e073d98eba1bd164d3e74edababa5325245e0cdd625f1c91&shop=moto-…myshopify.com&timestamp=1744648737 HTTP/2.0”, upstream: “fastcgi://unix:/var/run/php/php8.1-fpm.sock:”, host: "seoking.

2025/04/14 16:38:59 [error] 2984549#2984549: *3957981 FastCGI sent in stderr: “PHP message: ENTRY” while reading response header from upstream, client: 187.246.19.27, server: seoking.engageify.com, request: “GET /dashboard?embedded=1&hmac=68cbafe554486f8aede07d89dc52937c6341195a6456a592f4819ae1bdddc408&host=YWRtaW4uc2hvcGlmeS5jb20vc3RvcmUvbW90by1yYWQtY29t&id_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczpcL1wvbW90by1yYWQtY29tLm15c2hvcGlmeS5jb21cL2FkbWluIiwiZGVzdCI6Imh0dHBzOlwvXC9tb3RvLXJhZC1jb20ubXlzaG9waWZ5LmNvbSIsImF1ZCI6ImY0YTJhOWQyMjM3ZDZmOWIyODllOWU0MjdmNmUzZDgyIiwic3ViIjoiODk0ODM1NDI3NDgiLCJleHAiOjE3NDQ2NDg3OTcsIm5iZiI6MTc0NDY0ODczNywiaWF0IjoxNzQ0NjQ4NzM3LCJqdGkiOiI1YWU4YjMyZi04NjdiLTRmZDQtOTEwZC03ZmJmNjI4ZDY4OTUiLCJzaWQiOiI1NTM4MGQ2OC02NGQ3LTRhN2QtYWEwNy0xOTk5Y2ZmZGI0NjciLCJzaWciOiJjNzMzZGY3OWNkOWRmNDVlNDIxZmU1YmZjYjg2OTQwYmFiMzMwYjJiZDVhOTQyZGFlOTFiYWZkNGM2MzU1MmM4In0.lc2XWhKP6rs_ztCb1rydA4dYuOrUwnrV__AdL3sN3bk&locale=es-MX&session=bf5ade7bbb94c405e073d98eba1bd164d3e74edababa5325245e0cdd625f1c91&shop=moto-…myshopify.com&timestamp=1744648737 HTTP/2.0”, upstream: “fastcgi://unix:/var/run/php/php8.1-fpm.sock:”, host: "seoking.

[jason_engage]

Does anyone know how to stop these double requests in the Shopify admin? The first one is some preloadIframe request, and its hurting my app load speed. Since its identical i can’t target it and stop it. Seems to only happen on MacOS devices / browsers. Anyone seen this?

seems related to this issue:

App bridge reloads app multiple times on first open

But there is no prefetch=1 added to the first request.

[jason_engage]

If anyone is seeing this issue on their server - you must setup caching to prevent this.

# This will match /dashboard and /dashboard?anything
   location = /dashboard {
       # Fastcgi cache configuration
       fastcgi_cache shopify_cache;
       fastcgi_cache_key "$scheme$host$request_uri";  # Include the query string in the cache key
       fastcgi_cache_valid 200 30s;
       
       # Fastcgi cache lock to prevent duplicate requests
       fastcgi_cache_lock on;
       fastcgi_cache_lock_timeout 5s;
       
       # Debug headers
       add_header X-Cache-Status $upstream_cache_status;
       
       # PHP processing
       include fastcgi_params;
       fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
       fastcgi_param SCRIPT_FILENAME $document_root/index.php;
       
       # Cache control headers for browsers
       add_header Cache-Control "private, max-age=30";
   }

[jason_engage]

But it’s still an issue if you send a merchant to a different path (ie. the admin links), such as /process

in which case Shopify sends one request to /dashboard and one to /process

in fact, if you send a merchant to /dashboard/path it sends 2 requests: 1 to /dashboard and one to /dashboard/path.

Why? This is really crazy, how can i have it send the 1st request to /ok?

I want the 1st request to simply end with OK and not force my server to process it - or stop sending 2 requests entirely.

[jason_engage]

Did a team at Shopify just update this to try and fix it?

Now its worse than before.

Its sending 2 different requests (hmac changes now), and timestamp is sometimes off by 1.

At least before this could be addressed by using NGINX Caching - now its totally screwed up. Can anyone responsible for this reply and explain whats going on before the scenes???

[Lorenzo_Verheecke]

Experiencing the same issues, which is causing a numerous amount of complaints for our apps right now. App actions are being triggered twice now.

Testable by:

• In the admin overview > orders overview > hold ctrl + click one specific order, you’ll notice it opens twice (double event listeners? …)
• If you have an app action that performs a request in an app without a view being rendered aka: a direct action > this will happen twice.

This issue made us push changes to all apps that have app actions with direct actions > We now have to add a view/popup with a confirmation button for users to confirm their action (once)…

[jason_engage]

Yup, I had to setup an in-between screen as well.

[Lorenzo_Verheecke]

This seems to be resolved as of 26/06/25". The priority of this issue does seem pretty high… so it would have been nice of Shopify to at least show some sign of life/recognition on this issue (also after contacting support a couple of times regarding this issue).

[huykon225]

I still facing with the same issue, the request /app dashboard run twice with different hmac

As I debug on the code, if 1 route have too much code then it will run twice. I don’t know exactly the issue but I guess that we have a threshold in component code size in a route

[jason_engage]

I just tested this on chrome, macos, embedded app.. I do not see the double request issue. It used to be an issue but they solved it, and it still appears solved for me. Anyone can verify again that might be useful since this is a nasty bug ( but it appears solved to me ).

[nunof]

@huykon225 I can see the behaviour you are referring to in our app as well, but this doesn’t seem to have any impact. It seems that only the first request is rendered, the other runs in parallel for some reason. @Henry_Tao from the AppBridge team mentioned in the past that they trigger parallel requests to preload stuff, so maybe it’s that.

[jason_engage]

Mine only shows 1 request, which is how it should be.

In the past ive seen it also have a /dashboard (with no query string) - but this one is a call to shopify and doesn’t hit our server.

In my opinion, most likely, maybe you have some sort of issue with your server, it’s reloading the page for some reason (maybe due to the app entry point) or shopify is adjusting the entry point. Not sure exactly, but if its not the iframe bug, its probably related to server config.

[nunof]

You most likely have an SPA, seems that is only happening for server-side rendered apps.

[jason_engage]

I’d be trying to figure out why 19kb is taking 2-5s, spa or not. (=server config)

[huykon225]

I also agree with you that this is the server issue because I run same on my localhost, it only take 200-300ms. I’m using Flyio server with 3 regions, 1 CPU & 1gb Ram