next.js: Expiration of the request when hosted on Firebase / Route Handlers POST

Verify canary release

  • I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.15.0
      npm: 9.5.0
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.4.4-canary.0
      eslint-config-next: 13.4.3
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.4

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true)

Link to the code that reproduces this issue or a replay of the bug

https://github.com/slecoustre-vulog/bug-route-handler

To Reproduce

index.js

const {
    https: { onRequest },
    scheduler: { onSchedule },
    logger,
} = require('firebase-functions/v2');
const { initializeApp } = require('firebase-admin/app');
const next = require('next');
const https = require('https');
const tools = require('normalize-diacritics');
const { parse } = require('url');
const LRU = require('lru-cache');

initializeApp();

const nextConfig = require('./next.config');

const nextAppsLRU = new LRU({
    // TODO tune this
    max: 3,
    allowStale: true,
    updateAgeOnGet: true,
    dispose: (server) => {
        server.close();
    },
});

exports.web = onRequest(
    {
        concurrency: 300,
        region: 'europe-west1',
        minInstances: 1,
        memory: '1GiB', // '512MB',
    },
    async (req, res) => {
        const { hostname, protocol, url } = req;
        const port = protocol === 'https' ? 443 : 80;
        const key = [hostname, port].join(':');

        let nextApp = nextAppsLRU.get(key);
        if (!nextApp) {
            nextApp = next({
                ...nextConfig,
                dir: process.cwd(),
                hostname,
                port: process.env.NODE_ENV === 'development' ? 5001 : port,
            });
            nextAppsLRU.set(key, nextApp);
        }

        await nextApp.prepare();
        const parsedUrl = parse(url, true);

        await nextApp.getRequestHandler()(req, res, parsedUrl);
    }
);

src/app/api/route.ts

import { NextRequest, NextResponse } from 'next/server';

export const GET = () => NextResponse.json({ message: 'Hello, world!' });
export const POST = async (req: NextRequest) => NextResponse.json({ message: 'Hello, world!', body: await req.json() });

Describe the Bug

During development everything works fine (npm run dev) but when you build and execute everything in firebase it doesn’t work anymore.

but the same development worked very well in version 13.2.

in version :

  • 13.4.2, I have the error: TypeError: Response body object should not be disturbed or locked
  • canary, I have a timeout of 60s

If there is no Body then it works very well.

Expected Behavior

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

NEXT-1590

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 14
  • Comments: 36 (2 by maintainers)

Most upvoted comments

The bug is still present in version 13.4.9. Is it normal that the Nextjs team does nothing to solve this problem?

😦

@AlexBrasileiro firebase’s “Integrate web framework” feature does the same thing i did. but in my project i need to have several functions (scheduler, …). so i wrote this feature. but i tried a lambda project with the “Integrate web framework” feature and i have the same problem.

when i’m in dev (localhost and npm run dev), the code works fine. but as soon as it’s hosted by firebase, emulator (dev or prod) or online (prod), i have the same problem.

Not using firebase or even the production server. I’m getting this error on my DEV server. any updates?

This has been addressed with the release of firebase-frameworks@0.11.0 https://github.com/FirebaseExtended/firebase-framework-tools/pull/122 it turns out the root cause was that Cloud Function’s use of body-parser middleware was spending the Readable buffer. Proxying the request through an IncomingMessage seems to provide a reliable fix.

this is indeed very annoying… did you switch to the old pages API as a workaround ?

seeing this in 13.3.4, too

I’m not sure, sadly. This seems like a packaging issue (does that module exist in the deployed artifact?)

Tried again today from a clean slate. Set the package version in non-dev and it deployed, and my POST bodies are working again.

Has anyone found a solution to this issue? I’ve encountered the same error (TypeError: Response body object should not be disturbed or locked) when trying to make a POST request to a handler with a body.

@vual The only solution I’ve found so far to avoid redoing all the code for the POST, DELETE … APIs is to use expressjs and process the calls. Post(pattern) => custom handler ** => Nextjs handler

Yes, it’s the body that poses the problem, whatever the method.