[🐛 Bug]: next/cache Supports Only Suspense Cache - Is It Intended?

[susemeee]

next-on-pages environment related information

System:
        Platform: darwin
        Arch: arm64
        Version: Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:43 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6000
        CPU: (10) arm64 Apple M1 Pro
        Memory: 16 GB
        Shell: /bin/zsh
Package Manager Used: npm (9.6.6)

Relevant Packages:
        @cloudflare/next-on-pages: 1.7.3
        vercel: N/A
        next: N/A

Description

Result of arbitrary fetch response used in the codebase - In my case 3rd party API is used - does not seem to be cached in the network.

I've been closely examining #419 and find out that handleSuspenseCacheRequest handle only the suspense cache (which name also suggests).

Nextjs' data caching supports (and deployment on Vercel actually caches it) data from arbitrary API request, however, the scope of the patch is limited to the suspense cache. It is intended, or is there a way to extend the caching behavior?

Reproduction

1. Set up Next.js project using fetch to call external API
2. Build the project npx @cloudflare/next-on-pages@1
3. Start worker to test wrangler pages dev .vercel/output/static/ --compatibility-date 2022-11-30 --compatibility-flags="nodejs_compat"

Patched fetch will always make a request to remote without caching because handleSuspenseCacheRequest would not handle the request.
Actual deployment also does not seem to cache the request.

Pages Deployment Method

Pages CI (GitHub/GitLab integration)

Pages Deployment ID

No response

Additional Information

No response

Would you like to help?

• Would you like to help fixing this bug?

[james-elicx]

Can you share an example code snippet that results in this problem, please?

You can see a deployed demo that uses the suspense cache (aka fetch/data cache) at https://next-cache-demo.eli.cx/ and it works, so i imagine it is related to how the request is being done. This demo is a deployment of https:/james-elicx/next-geolocation-pages/blob/a5d43de1a3d2b6b09375b5544caab0e4bfd94ffc/app/page.tsx.

[susemeee]

Sure! This is the minimum reproducible project.

More thing I've discovered is that caching actually works, however it causes problem with supabase client is used together.

As per this and this Supabase client provides method to patch their fetch function.

If I put log in applyPatch function from utils/fetch.ts then I can see diverged results like below.

[
  'https://INTERNAL_SUSPENSE_CACHE_HOSTNAME.local/v1/suspense-cache/972cbca3986b2b8e4b075eb9f770ecce20cd3dd0a5179eb3a458b0bb86bd27f6',
  {
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
      'x-vercel-cache-item-name': 'https://timeapi.io/api/Time/current/zone?timeZone=UTC',
      'x-vercel-cache-tags': 'TAG',
      'x-next-cache-soft-tags': '_N_T_/layout,_N_T_/page,_N_T_/'
    },
    next: {
      internal: true,
      fetchType: 'cache-get',
      fetchUrl: 'https://timeapi.io/api/Time/current/zone?timeZone=UTC',
      fetchIdx: 2
    }
  }
]
[
  'https://@@@.supabase.co/rest/v1/quests?select=*&limit=1',
  {
    body: undefined,
    credentials: undefined,
    headers: Headers(4) {
      'accept-profile' => 'public',
      'apikey' => @@@,
      'authorization' => @@@,
      'x-client-info' => 'supabase-js-node/2.38.4',
      [immutable]: false
    },
    integrity: undefined,
    keepalive: undefined,
    method: 'GET',
    mode: undefined,
    redirect: undefined,
    referrer: undefined,
    referrerPolicy: undefined,
    window: undefined,
    duplex: undefined,
    signal: undefined,
    next: { fetchType: 'origin', fetchIdx: 2 }
  }
]

The patched fetch of Supabase client seemed not to go on some internal caching behavior. I'm not sure what actually causes a problem. In Vercel deployment, whole caching thing including Supabase fetch works without problem, which makes me more confusing.

[susemeee]

Dig deeper, Supabase patched fetch not behaves as expected because Next.js fetch function can't obtain StaticGenerationStore.

I think it is not a next-on-pages problem (maybe supabase client's problem?), and it seems to work as expected. In favor of this I'm closing this issue.

Additionally, Vercel deployment with edge runtime also has exact same issue.