Next.js Middleware Error

[crisp tangle]

When I'm following this guide: https://trigger.dev/docs/documentation/guides/platforms/nextjs#middleware
I got this error: Error parsing /(api((?!/trigger))|trpc)(.*)
Reason: Capturing groups are not allowed

What did I do wrong?

[granite sequoia]

Can you share your full middleware file and what version of Next.js you're using? I assume you're using the app router?

[crisp tangle]

import type { NextRequest } from 'next/server'
import { NextResponse } from 'next/server'
import { verifyRequestOrigin } from 'lucia'

export function middleware(request: NextRequest) {
  if (request.method === 'GET') return NextResponse.next()

  const originHeader = request.headers.get('Origin')
  const hostHeader = request.headers.get('Host')
  if (!originHeader || !hostHeader || !verifyRequestOrigin(originHeader, [hostHeader])) {
    return new NextResponse(null, {
      status: 403
    })
  }

  return NextResponse.next()
}

export const config = {
  matcher: ["/((?!.*\\..*|_next).*)", "/", "/(api((?!/trigger))|trpc)(.*)"],
}

I'm using the pages router

[granite sequoia]

Hmm this is strange because it definitely works for a lot of people, perhaps it's a version issue.

I don't think we actually need that capturing group though so you could try this:
/(api(?!/trigger)|trpc)(.*)

[ruby kiln]

Same team here.

It doesn't throw an error anymore but the current matcher doesn't block /api/trigger routes, so I can still see it getting passed in the middleware and subsequently getting this error

[granite sequoia]

Do you mean that it does block /api/trigger?

[ruby kiln]

As in hitting /api/trigger will still match with the matcher so the middeware is parsing /api/trigger requests

Just to be sure, we need to negate /api/trigger paths in the matcher so it doesn't go through nextjs's middleware, correct?

[granite sequoia]

Yes

You could just check in your middleware function for the /api/trigger path and pass it through

I think

[ruby kiln]

Yeah, literally just thought of that. Was hoping for a cleaner solution.

But it's Nextjs, what can we do? 😛

[granite sequoia]

I think it might be that your first pattern is matching /api/trigger actually

[ruby kiln]

Hmm, let me check that

[granite sequoia]

This is such a stupid system… it looks like in this example they have to repeat the negative lookahead on each 🤦‍♂️

[ruby kiln]

I saw that and there isn't more docs to go on with that syntax 😂

[ruby kiln]

You are right! 🤦‍♂️

Thanks a lot and sorry for the troubles!

[granite sequoia]

Hmm this is strange because I'm 99% sure it works with the app router

Ok that's good at least 😆

[ruby kiln]

It's progress for us so I'm happy 😜

Off topic @granite sequoia , but when can we expect the GA release for V3?

We working on V2 syntax but it's nice to know when V3 roughly gets released so we can plan ahead

[granite sequoia]

That's a good question and I think we need to do better at communicating what we mean by "Developer Preview".

Basically some things are already mature and a lot of better (and more reliable than v2 even because the core model is better). Some things work but aren't amazing. And finally there are some things that v2 supports which v3 doesn't yet.

So basically it depends on your use case.

What exactly are you going to use Trigger for? I can help figure it out.

[ruby kiln]

We are a booking platform so far these are the scenarios I have with trigger:

• Send Whatsapp reminders before 30 mins before the start of each booking (and handle callbacks via endpoints, easily)
• Do some preliminary checks for validity at the start of each booking (so run some code at each of booking's start time)

So far this is it for now but the big plan is that this pipeline of events and triggers I suspect will be complicated really quickly

And going on a tangent, Trigger is REALLY good so far during my testing. I feel it's very productive for me and my team as part of our toolkit so thank you guys 🙏

The only thing that isn't so great tbh in V2 is the typesafety of events (right now using one of the hacks the community made, the one inspired by T3 theo)

[granite sequoia]

Ah yes that is annoying. We made it so when you call trigger() or batchTrigger() in v3 it has the correct types.

and handle callbacks via endpoints, easily
How are you doing this at the moment? Are you using us for this?

[ruby kiln]

Yup, using defineHttpEndpoint

[granite sequoia]

Ah ok, we don't have any kind of webhook support in v3 yet and it won't be for a while. Our current recommendation for v3 customers is to just receive the webhooks to your app and then call trigger or batchTrigger on tasks where you need to.

[ruby kiln]

We'll definitely wait for V3 becomes GA for commercial point of view but I'm excited what you guys are cooking and really looking forward to give push trigger on production 👍

I'm sorry to bother you but I have one last (unrelated) question (weird behavior)

We're using prisma to fetch data when we run our tasks.

I have two tasks. One task that fetches the data using prisma returns a date object. Another task that uses the fetched date to run some code with it.

The weird thing is that the first task sees the typeof date correctly as object but as soon as it gets to the second task, it seems that the (exact same unmodified) date object is manipulated as becomes a string type (not expected)

Is this trigger's expected behavior?

Found a good way to kinda reproduce this

When I have this following code:

• I expect that fetchedDate at line 33 and date at line 43 are both Date types (just like in typical JS function) so it should return Object type when run typeof for both of them

However, I'm getting both fetchedDate and date as string instead

This seems like a big issue or am I missing a big piece something else?

[granite sequoia]

Hey, yes this is a limitation of runTask in v2. The data you return needs to be serializable using JSON.stringify and JSON.parse. We did at one point have a TypeScript error for this if you tried to return non primitive data but it caused a load of issues with APis.

In v3 we use SuperJSON which allows dates, BigInts and Maps

[ruby kiln]

I can imagine that, ouch 😓

Problem is that we are using a monorepo so we are reusing a lot of functions. It’s hard (and makes our code clunky) to change all that so it’s compatible with the serialization

I do appreciate you answering, that is a big clarification

I think this makes a big difference to jump for V3 for us. I prefer the reliability and consistency of results. Wdyt? Should we go for V3?