iframeplaywrightshopify-appfly

Playwright iframe connection reset errors for Shopify embedded app


I have a Shopify app deployed to fly.io for e2e testing but I am experiencing issues with running tests after the initial auth setup has taken place and storageState saved.

The majority of the time (not 100% of the time), when the next Playwright project is run, using the preserved storageState the Shopify embedded app iframe will refuse to load with a "the connection was reset" error.

Shopify embedded app iframe showing connection reset error

After the initial auth setup is run successfully, including loading the embedded iframe app page successfully, the browser state will be getting reset for subsequent tests. I wonder if the reset is causing the issue somehow as if all the test steps are bundled together this issue is a lot rarer, though still somewhat infrequently happening when the fly.io service could be stale and so unloaded.

While these connection reset issues are happening I can happily click around the app screens in my usual day-to-day Chrome browser. I occasionally see these connection reset errors there too though if the tab has been left sitting for extended time periods, but a quick page refresh resolves the issue.

My playwright.config.ts for the relevant projects:

projects: [
  {
    name: 'setup',
    use: { ...devices['Desktop Chrome'] },
    testMatch: /global\.setup\.ts/,
  },
  {
    name: 'chromium',
    use: { 
      ...devices['Desktop Chrome'],
      storageState: STORAGE_FILE,
    },
    dependencies: ['setup'],
  },

Any ideas what the issue could be? It's preventing me from building up my suite of e2e tests to provide confidence when making changes to the app.

I'm wondering if this is related to general network connectivity to fly.io as to install the CLI tool from them I was forced to either turn off IPv6 or add a registry setting (Windows 11) to prefer IPv4 over IPv6.


Solution

  • As a test I deployed the app to DigitalOcean and the issue was immediately resolved. So my conclusion is that the issues were a result of fly.io network issues. Once I remembered about the trouble I had installing the fly CLI tool I began to suspect this was the case.