How to programmatically differentiate when server code run in Server Action / Route handler context vs rendering-a-page context

[MonstraG]

Summary

https://nextjs.org/docs/app/api-reference/functions/cookies api has restrictions: setting or deleting of cookies is only available in Server Action / Route handler, and not on, say, page render.

How do I programmatically detect in which situation I am?

I writing data-fetching code with authentication. If my database API returns 401, I would need to refresh access token, but that is impossible on page render, so instead I need to redirect to login page with redirect(). If my server function or route handler call has returned 401, I can refresh access token and try again.

I would like to have one fetchAuth which does first or second depending on where it was called from, how do I know that?

Example

No response

[MonstraG]

At the moment, I'm using this:

async function isInServerActionContext(): Promise<boolean> {
	try {
		const resolvedCookies = await cookies();
		resolvedCookies.delete("if this delete succeeds, i must be in server action context");
		return true;
	} catch (error) {
		if (
			error instanceof Error &&
			error.message.includes("Cookies") &&
			error.message.includes("nextjs")
		) {
			// looks like the Next.js's error about cookies being modifiable only in Server Action or Route Handler,
			// we are not there.
			return false;
		}

		// some unrelated error happened, let it go
		throw error;
	}
}

[icyJoseph]

I think there's two takes here, both bother me a bit - but AFAIK, this kind of introspection about who called me, leans itself to this.

The verbose, brittle way to have your custom function always redirect - unless a flag is passed to it, telling to regenerate the access token in case of failure - or make the intention a required parameter passed to the function. AKA, you tag it manually. Likely won't ever break though.

One thing that's not very documented, I'd say mostly because it is an implementation detail, is that there's a next-action header in server actions, that has some opaque ID information about the action. I guess, if that's present you can infer it is a server action, until some day in the future, it maybe breaks, because the header name changes, or it is removed before triggering the server action, who knows...

[MonstraG]

bothered by introspection

Yes, in general I don't like call site introspection too. Alternative solution would be to somehow expose initial Request that gets me the layout+page, but given that Next.js wants to start responding as fast as posible, so it sends the headers back, this is explicitly not possible, so I'm stuck in this funny situation. But a general server would of course have access to Request and would be able to correctly set cookies each time, side-stepping the issue entirely.

tag it manually

Manual parameters on every call site would work of course, but in reality those fetch calls already have a bunch of manualy set parameters:

• url
• method
• body (or lack thereof)
• whether to use cookies for auth at all (some endpoints are public)

And because there are like 200 requests around the application, what are the chances that developer makes a mistake and passes incorrect parameter at least once? I wanted to prevent mistakes as much as possible, so introspection it is.

opaque ID information about the action

I definitely don't want to rely on undocumented opaque ID, and given that I want same behavior on Server Action and Route Handler (and it seems implied that route handlers don't have the ID), that wouldn't work for me either.

It seems I have to stick with funny try/catch.