Bug: Double Requests from Shopify Admin iFrame Issue

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.

1 Like

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:

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


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";
   }

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.

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???

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)…

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

1 Like