Issue with Opening Product Pages Directly or Hard Refreshing in WooNuxt

[grandant]

Description of the Problem

When accessing product pages directly via URL or performing a hard refresh, the page fails to load correctly. This leads to a 404 or 500 error or a blank page (depending on error handling in the template), even though navigating to the same product page through the site works as expected. The issue seems related to how the WooNuxt template handles data fetching and SSR when interacting with the WordPress and GraphQL backends. This only happens on the deployed app.

Steps to Reproduce

1. Deploy the app (tested on NuxtHub)
2. Visit the products page directly by entering the product URL or refreshing the page while on a product page.
3. Observe that the products page shows:

Could not fetch products from your store. Please check your configuration.

4. Navigate to the products page using the link in the header, and the data loads correctly.

Software versions

• Nuxt version: 3.13
• WooNuxt version: 1.0.58
• GraphQL version: 1.28.1
• WPGraphQL CORS: 2.1
• WPGraphQL WooCommerce: 0.21.0
• WordPress version: [Version]
• WooCommerce version: 9.2.3

Additional Details

Disabling SSR for the products and categories pages solves the problem for the parent pages themselves:

nitro: {
    routeRules: {
      '/': { prerender: true },
      '/products/**': { ssr: false, swr: 3600 },
      '/categories': { ssr: false, swr: 3600 },
      '/checkout/order-received/**': { ssr: false },
      '/order-summary/**': { ssr: false },
    },
  },

However, the issue is still persistent for individual product listings. Perhaps it's worth mentioning that the GraphQL backend responds slowly (over 1s on average). Both the backend and the frontend are deployed and live.

Screenshots

EDIT: This issue comes from static generation vs using npm run build which is the default setting on Cloudflare (via NuxtHub). I reverted all changes to the template and deployed on Cloudflare with the generate option and all problems are gone. If that's the expected behaviour, please close this issue but perhaps mention this in the docs.