N
Nuxt9mo ago
Flo

API Routing broken

I've seen reports before and I couldn't believe it... and now I'm here. Nitro-Routes:
'/api/projects/:projectId/os/:resourceType': {
'get': Simplify<Serialize<Awaited<ReturnType<typeof import('../../server/api/projects/[projectId]/os/[resourceType]/index.get').default>>>>
'post': Simplify<Serialize<Awaited<ReturnType<typeof import('../../server/api/projects/[projectId]/os/[resourceType]/index.post').default>>>>
}
'/api/projects/:projectId/os/networks': {
'post': Simplify<Serialize<Awaited<ReturnType<typeof import('../../server/api/projects/[projectId]/os/networks/index.post').default>>>>
}
'/api/projects/:projectId/os/:resourceType': {
'get': Simplify<Serialize<Awaited<ReturnType<typeof import('../../server/api/projects/[projectId]/os/[resourceType]/index.get').default>>>>
'post': Simplify<Serialize<Awaited<ReturnType<typeof import('../../server/api/projects/[projectId]/os/[resourceType]/index.post').default>>>>
}
'/api/projects/:projectId/os/networks': {
'post': Simplify<Serialize<Awaited<ReturnType<typeof import('../../server/api/projects/[projectId]/os/networks/index.post').default>>>>
}
2 concurrent routes: one for :id/os/:resourceType (generic handler) and one for :id/os/networks (edge case handling). Latter only has a post-handler! Code executed (server side):
const flowApi = $fetch.create({ headers: event.headers, query: queryParams });

// Get networks
const networks = await flowApi<Network[]>(
`/api/projects/${routeParams.id}/os/networks`
);
console.log("Got networks: ", networks);
const flowApi = $fetch.create({ headers: event.headers, query: queryParams });

// Get networks
const networks = await flowApi<Network[]>(
`/api/projects/${routeParams.id}/os/networks`
);
console.log("Got networks: ", networks);
This is a get-Request. The edge case handler does not get called, that's correct. The generic get handler gets called - and suddenly the resourceType no longer exists in the event. It should look like (after removing the edge case handler):
matchedRoute: {
path: '/api/projects/:projectId/os/:resourceType',
handlers: [Object],
params: [Object]
},
params: {
projectId: '05caa06f-ac5a-4ab0-99f4-98fe9380ac99',
resourceType: 'networks'
}
matchedRoute: {
path: '/api/projects/:projectId/os/:resourceType',
handlers: [Object],
params: [Object]
},
params: {
projectId: '05caa06f-ac5a-4ab0-99f4-98fe9380ac99',
resourceType: 'networks'
}
It really looks like (with edge handler):
matchedRoute: {
path: '/api/projects/:projectId/os/networks',
handlers: [Object],
params: [Object]
},
params: { projectId: '05caa06f-ac5a-4ab0-99f4-98fe9380ac99' }
matchedRoute: {
path: '/api/projects/:projectId/os/networks',
handlers: [Object],
params: [Object]
},
params: { projectId: '05caa06f-ac5a-4ab0-99f4-98fe9380ac99' }
The matchedRoute points to the correct path. But if it would be really using it, it must fail because there's no get-handler for that path.
6 Replies
Flo
FloOP9mo ago
matchedRoute: {
path: '/api/projects/:projectId/os/networks',
handlers: {
post: [Function (anonymous)] {
__is_handler__: true,
__resolve__: [Function: resolveHandler]
},
get: [Function (anonymous)] {
__is_handler__: true,
__resolve__: [Function: resolveHandler]
}
},
params: { projectId: '05caa06f-ac5a-4ab0-99f4-98fe9380ac99' }
}
matchedRoute: {
path: '/api/projects/:projectId/os/networks',
handlers: {
post: [Function (anonymous)] {
__is_handler__: true,
__resolve__: [Function: resolveHandler]
},
get: [Function (anonymous)] {
__is_handler__: true,
__resolve__: [Function: resolveHandler]
}
},
params: { projectId: '05caa06f-ac5a-4ab0-99f4-98fe9380ac99' }
}
The get-entry in that handler object is wrong. @danielroe Good morning. Before I spend time creating a repro for a bugreport... is this known?
danielroe
danielroe9mo ago
I think the post/get are not included in the routing - so basically the route is matched first and then the method is evaluated.
Flo
FloOP9mo ago
so... by design? Not a bug?
danielroe
danielroe9mo ago
I think it's definitely worth a discussion. I think it's a limitation of how routing is implemented in nitro using radix3 (a consequence of speed/perf decisions) - but I know pooya is rethinking things for a new version of radix3, and this might be on his list
Flo
FloOP9mo ago
Alright, I'll open up an issue in github, with repro. The current implementation ... hurts. Badly.
danielroe
danielroe9mo ago
Thank you ❤️
Want results from more Discord servers?
Add your server