Is it possible to run an async function AFTER the response has been sent ?

[dotlouis]

Hello everyone,
I'm currently implementing a /signup API route.
It goes like this:

1. Receive the request
2. Wait for the new user to be saved in the database
3. Acknowledge to the client that the account has been created with res.status(200).end()
4. Post (fetch) to another "long-running-ish" (~5s) lambda to set up the user account with various operations.

In pseudo-code it looks like this:

export default async (req, res) => {
  await saveToDb(req.body);
  // 👇 notice how there is no await here
  fetchLongRunningOperation().then(() => /* This promise never gets resolved */)
  res.status(200).end();
}

The thing is that in its current form, the fetchLongRunningOperation() promise never gets resolved (only on Vercel, locally it works). I suspect that once the response has been sent off, the lambda somehow gets shutdown.

However, when I do await for the task, it works:

export default async (req, res) => {
  await saveToDb(req.body);
  // 👇 here is the await
  await fetchLongRunningOperation().then(() => /* It works ! */)
  res.status(200).end();
}

I dived into the Vercel and NextJS docs without finding any information related to this behavior.
Lambda limits do not mention such a thing and the wait time is well below the 10s.

But because ~5 seconds of waiting is long when starring at a loading signup button, I would like to defer the execution of the task after the response has been sent.

Do you know of any ways I could do this?

[dotlouis]

So... I missed this bit of information from the limits page

This means that background tasks, also known as "fire-and-forget" is not supported. Once the function returns the response payload, it stops processing including any pending background tasks.

I guess I have my answer. I hope it helps if anyone is wondering why this was happening.

[AlbertMarashi]

Update for everyone:

• https://vercel.com/changelog/waituntil-is-now-available-for-vercel-functions

npm i @vercel/functions

import { waitUntil } from "@vercel/functions";

// within the api handler
// will continue running even after the response as been returned
waitUntil(new Promise(resolve => setTimeout(() => {
  console.log("hello world"), 500)
}));

// immediately return your response
return response

[nicholaschiang]

@dotlouis Have you figured out a workaround for this? Are you simply triggering the background task using a separate API route (that is called by the client but isn't waited on to show the signup as completed)?

[dotlouis]

To add to the discussion, with the new Edge Functions, it seems you can now "fire-and-forget" in a middleware:

The maximum duration for an Edge Function execution is 30 seconds, but the function needs to return a response in less than 1.5 seconds, otherwise the request will time out.

This means that you should return a response as soon as possible, and continue with any asynchronous workloads in the background, after returning the response.

[doxylee]

EDIT: This doesn't seem to work.. It allows code to run after res.json, but it also keeps the response from being sent until the code is run, which makes this solution pointless. Can anyone else confirm this?

Check out #12573 (comment)

There's some code from @sentry/nextjs that keeps lambda function alive so that sentry can send error logs after the response.

https://github.com/getsentry/sentry-javascript/blob/ad37109568479bb8459b76f6bdfe0c0bd54e66dd/packages/nextjs/src/utils/withSentry.ts

Based off it, I created a wrapper function that keeps lambda process running until the api handler is resolved.
I'm using it with the original withSentry, so I left out protection against scope bleeding, nextjs complaining res.end() not being called, etc
I deployed it and it seems to work, but I didn't test it throughly. There might be some bugs :(

export function withFireAndForget(
    handler: (req: NextApiRequest, res: NextApiResponse) => Promise<void>
) {
    return async (req: NextApiRequest, res: NextApiResponse) => {
        let promiseResolve: () => void = ()=>{throw Error("promiseResolved was not reassigned!")}
        const finishedPromise = new Promise<void>((resolve) => {
            promiseResolve = resolve;
        });
        const origEnd = res.end;
        res.end = async function newEnd(this: NextApiResponse, ...args: unknown[]) {
            await finishedPromise;
            //@ts-ignore
            return origEnd.call(this, ...args);
        };

        const result = await handler(req, res);
        promiseResolve();
        return result;
    };
}

[badazz91]

Hello I also have a related question to this topic - (maybe also the same). In the following code example, a mail is being sent via an external service. To speed up the response time of the serverless function, we do not wait (and do not care) about the response.

export default (req, res) => {
  const { body, method } = req;
  const { mail } = body;

  if (method !== 'POST') {
    return res.status(405).json({ message: 'Method not allowed.' });
  }

  const message = {
    subject: 'Your mail',
    text: '<very large template>', 
    html: '<very large html template>',
  };

  // fire and forget the promise to external service
  // for the example, lets say this takes 5 secs to be done.
  send(mail, message);

  return res.status(200).json({ status: 'ok' });
};

Now my question: Could it also be in this case, that send() is also cancelled in the middle of its request, before the external service has processed it, because the function is terminated after sending the 200 OK at the end?

Alternative would be this at the end of the function:

 return send(mail, message).then(() => res.status(200).json({ status: 'ok' }))

This way the function is terminated after the promise resolves completely. But this also means that the serverless functions runs longer.

What would be the best way?

Thanks for the help - @dotlouis.

And also an addition - is it a difference - when fire and forgetting to another of your serverless functions, or is it the same issue? E.g.

  // fire and forget to other serverless function
  // do not await
  post('<your-domain>/api/some-action');

  return res.status(200).json({ status: 'ok' });

[alanhett]

Same scenario here. Emails are slow and would love to be able to send them after sending response. This was a confusing issue because when testing locally Next.js doesn't behave this way, it behaves more like Express where code can be executed after HTTP response. Why not just allow the function to run for the full 60 seconds (or whatever limit the plan allows)?

[Christopher-Hayes]

Yeah that's the dilemma I've been trying to figure out.

I know from past experiences that if you make a request that you don't await as the last thing you do in an AWS Lambda, that request CAN get terminated before the request is sent out. And then if you await the request, we're back at square one with a different function!

Only possibility I see is to crudely await a setTimeout to ensure the request gets sent before terminating the function. But, that is far from ideal.

[ahmafi]

So what is the workaround to have some jobs running after we send the response? What about when we are not in a serverless environment? And also in next 13 we are returning the response which I think then it means we can't run jobs after sending the response?

[alanhett]

Unless anything has changed since my original post, the workaround is to use another service to handle the long-running parts.

[Christopher-Hayes]

Using a job queue service like ServerlessQ would be the more robust way to do it. But, if you want to get into the weeds, there is a way to do what you're asking if you use an Edge function instead of a regular serverless function. The Edge API has a waitUntil function that lets you keep the function running after it returns a response. (However, note that the Edge has limits on runtime too)
https://vercel.com/docs/concepts/functions/edge-functions/edge-functions-api#waituntil

[enesien]

@Christopher-Hayes's suggestion waitUntil is perfect for this.

For those of you still working on this, here's a stripped down example of what I'm doing for a "fire-and-forget" type of edge function.

export const config: NextConfig = {
  runtime: 'edge',
}

export default async function handler(request: NextRequest, context: NextFetchEvent) {
  context.waitUntil(
    // edge function will wait until the promise is resolved/rejected
    new Promise<void>(async (resolve, reject) => {
      await someLongFunction()
      resolve()
    })
  )
  // return the response so the caller doesn't have to wait
  return new Response(`Working on it!`);
}

Then you can call this edge function from a standard serverless function and look for the 200 response to see if your edge function accepted the request.

I went a step further and passed a "callback webhook" that my edge function calls when it's completed with its operations. This helps prevent your serverless functions from timing out while still allowing for certain operations that take a long time, like OpenAI calls 😄

[moshest]

Please note it does NOT support app router at the moment:

The waitUntil() method is not currently supported with app-router in Next.js. Vercel is working to implement this functionality.

[agentpietrucha]

Just FYI, waitUntil() is already available in app router with both nodejs and edge runtimes: https://vercel.com/changelog/waituntil-is-now-available-for-vercel-functions

[javierojgs]

I encountered a similar challenge with email sending, and after a thorough analysis, I recommend a customized solution for your Next.js application. This involves creating a dedicated endpoint to efficiently handle the asynchronous email task. It's crucial to note that this approach includes the creation of a new serverless function rather than a simple inner function within the existing serverless function.

Important Note: The process of sending an email may take up to 7 seconds. Additionally, it's essential to be mindful of the limitations associated with the Vercel Hobby plan, which offers a maximum function runtime of 10 seconds per execution. For a detailed overview of Vercel function runtimes and limitations, please refer to the documentation here. Ensure that your email task aligns with these constraints to maintain optimal performance within the specified plan.

Here's a refined breakdown of the proposed solution:

1. Create a New Endpoint:
   Develop a dedicated endpoint within your Next.js application specifically designed to handle the asynchronous email task. This endpoint will serve as a specialized entry point for initiating and managing email-related operations.

2. Update Axios Request Handling:
   Adjust the Axios request to utilize the newly created endpoint for the email task. Instead of using await in a try-catch block, adopt a non-blocking approach with axios.post().then().catch(). This modification allows the request to be initiated without waiting for its completion.

3. Implement Endpoint Logic:
   Within the new endpoint, implement the necessary logic to handle the email task asynchronously. This includes addressing any specific timing considerations associated with the duration of the email task.

By introducing this new endpoint to your Next.js application, we enhance modularity and organization, providing a streamlined solution for efficiently managing asynchronous email operations. I welcome any discussions or feedback on this proposed update.

[FelixZY]

Here's how I did it: https://github.com/dansdata-se/api/commit/b4f27fc4bda34e282c733bd32ff3fbdb3389cf03

In my case, I wanted to log requests to my database with status code and execution time which is only known after the response is produced. What I did was that I wrapped my API routes with a monkey-patch around NextApiResponse which delays the closure of the response until all tasks have completed. This does mean the user has to wait for my tasks to complete before receiving their result but did prevent a MAJOR rewrite.

// eslint-disable-next-line @typescript-eslint/unbound-method
const originalEnd = res.end;

let endArgs: unknown = undefined;

// @ts-expect-error TypeScript does not like the "unknown"s here
res.end = (...args) => (endArgs = args);

await handler(req, res);

if (endArgs === undefined) {
  originalEnd.apply(res);
} else {
  // @ts-expect-error TypeScript infers an incorrect type for endArgs
  originalEnd.apply(res, endArgs);
}

[AlbertMarashi]

You can now!

import { waitUntil } from "@vercel/functions";

// within the api handler
// will continue running even after the response as been returned
waitUntil(new Promise(resolve => setTimeout(() => {
  console.log("hello world"), 500)
}));

// immediately return your response
return response

npm i @vercel/functions

https://vercel.com/changelog/waituntil-is-now-available-for-vercel-functions

I accidentally found this by reading through the langfuse docs 😆 https://langfuse.com/docs/sdk/typescript/guide#option-1-waiting-for-flushasync-but-returning-immediately

[rezabrizi]

Can also be done within Express APIs too?