Pretty confident this isn't an issue with next-connect, rather something flawed with the approach below, which uses a shared handler across all API routes instead of separately importing next-connect in every route.
The issue
Nested routes are returning the wrong results if you hit one after another. For example, if you go to /api/foo => /api/foo/:id => /api/foo, you will get correct results on the first two calls, but the third will actually be calling the second route and is expecting an id, which throws an error.
Pretty confident this isn't an issue with
next-connect
, rather something flawed with the approach below, which uses a shared handler across all API routes instead of separately importing next-connect in every route.The issue Nested routes are returning the wrong results if you hit one after another. For example, if you go to
/api/foo
=>/api/foo/:id
=>/api/foo
, you will get correct results on the first two calls, but the third will actually be calling the second route and is expecting anid
, which throws an error.I'm running into this on a much larger project, so I pushed up a (very) simplified version of the issue here: https://github.com/kennethacohen/repro-next-routing-bug
..which is just a modification from something I'm following from @bmvantunes here: https://github.com/bmvantunes/youtube-2020-july-next-api-routes-next-connect/tree/master/src