[NEXT-1318] Unable to use context.waitUntil in Route Handler?

[s1973]

What is the improvement or update you wish to see?

When using pages router, we can use context on api routers:

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

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

const wait = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));

async function getAlbum() {
  const res = await fetch('https://jsonplaceholder.typicode.com/albums/1');
  await wait(10000);
  return res.json();
}

export default function MyEdgeFunction(
  request: NextRequest,
  context: NextFetchEvent,
) {
  context.waitUntil(getAlbum().then((json) => console.log({ json })));

  return NextResponse.json({
    name: `Hello, from ${request.url} I'm an Edge Function!`,
  });
}

while using app router, we got this from doc:

Currently, the only value of context is params, which is an object containing the dynamic route parameters for the current route.

so I am wondering how to use NextFetchEvent with route handler?

Is there any context that might help us understand?

I am trying to keep the function running after a response has been sent, as the vercel doc navigated, we can use waitUntil(), but it seems not approachable in App Router and Route Handler, can I get any thoughts? thanks

Does the docs page already exist? Please link to it.

https://nextjs.org/docs/app/api-reference/file-conventions/route#context-optional

_NEXT-1318

[oalexdoda]

Hey @s1973 have you managed to figure this out yet?

[oalexdoda]

@balazsorban44 is this a Next.js bug? And if so, any estimate as to when context.waitUntil would become available?

[balazsorban44]

Hi, it's more like a missing feature. when Route Handlers have been introduced this was not added to the initial implementation requirements.

But after some internal discussions, we think we should add it so there's feature parity with API Routes (edge).

It's now tracked internally.

[oalexdoda]

Hi, it's more like a missing feature. when Route Handlers have been introduced this was not added to the initial implementation requirements.

But after some internal discussions, we think we should add it so there's feature parity with API Routes (edge).

It's now tracked internally.

Got it. Thank you! Will keep an eye out since it's blocking us from migrating some pretty important routes to the app directory.

[oalexdoda]

Hey @balazsorban44 , is this being worked on yet by any chance? If so can I have a rough ETA? Thank you & I really appreciate it!

[raunakdoesdev]

+1 on this

Kind of strange that this was released without this feature. The types are literally wrong in saying there is this property that doesn't exist (waitUntil). Had to move some routes to page router as a result of it.

[kyb3r]

Any updates on this?

[anuraagvaidya]

+1 on this

Kind of strange that this was released without this feature. The types are literally wrong in saying there is this property that doesn't exist (waitUntil). Had to move some routes to page router as a result of it.

Were you able to access the context object using page router? Mine is an empty object.

[anuraagvaidya]

I was able to get around this issue by moving my long-running functions to middleware.js

export async function middleware(req, context) {
    if(/*match your path*/)
    {
        context.waitUntil(callFunctionsThatReturnsPromise);
    }
}

[oalexdoda]

Great workaround @anuraagvaidya , but pretty inconvenient for large apps with lots of moving pieces & routes. Really hoping to see native context support at a route level

[matannahmani]

any updates on this?

Edit by maintainers: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!

[sam3d]

The Next.js team has created an undocumented (and highly experimental) API for this: internal_runWithWaitUntil.

• 56381

• 56404

• 56720

⚠️ This is an internal API and will be removed soon. Please do not use.

• The Edge Runtime supports it in Server Actions, Route Handlers, and in an SSR context
• It delays cancellation of the worker for up to 30 seconds after the client disconnects (source)
• I've been using it in production on Vercel for a few weeks now, and it seems to work exactly as advertised without issue

"use server";

import { internal_runWithWaitUntil as waitUntil } from "next/dist/server/web/internal-edge-wait-until";

const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));

export async function action() {
  console.log("Request received");

  waitUntil(async () => {
    await sleep(10000);
    console.log("Waited for 10 seconds");
  });

  return "Returned immediately";
}

[maccman]

@sam3d I'm wondering if there's an update on when this is being planned to be released?

[PSoltes]

Yeah feels weird that there were 2(!!) major versions with app router released without this kinda important feature.

[kyb3r]

using internal_runWithWaitUntil

But any eta when the api will be stabilised in a release?

[maccman]

It's brewing! https://github.com/vercel/next.js/pull/65038

[Thinkscape]

Good news!

https://vercel.com/changelog/waituntil-is-now-available-for-vercel-functions https://vercel.com/docs/functions/functions-api-reference#waituntil

[mmkal]

It sounds like the above is specific to functions? It's not clear to me if it's supposed to be used in:

• edge middleware?
• node middleware?
• edge route handlers?
• node route handlers?
• edge server components?
• node server components?

I had a look at the implementation and it looks like it's getting context from globalThis, but it null checks both the context's existence and the waitUntil property on the context.

Edited: from adding logging which does roughly the same as the waitUntil export from @vercel/functions, it seems it is defined for middleware, server components and route handlers. When deployed to vercel - it isn't locally, which makes some sense. Not sure about non-vercel deployment environments, or node vs edge, but this is good enough for me! I'm still not sure why the docs only reference functions when it seems to work everywhere, so I might still be missing something.