Description
Describe the bug
When making post/put/patch requests to endpoints that accept multipart/form-data uploads (e.g., using@fastify/multipart), fastify-racing incorrectly triggers the abort signal for every request after the payload has been parsed.
To Reproduce
Run the following fastify app
// app.js
const fastify = require('fastify')()
fastify.register(require('fastify-racing'))
fastify.register(require('@fastify/multipart'))
fastify.post('/data', async (request, reply) => {
const signal = request.race()
const parts = request.parts()
const payload = {}
console.log('Signal before', signal.aborted) // false
for await (const part of parts) {
if (part.file) {
payload[part.fieldname] = await part.toBuffer() // to consume the stream
}
}
console.log('Signal after', signal.aborted) // true
await fetch('https://example.com', { signal }) // as a result, calls like this will always be aborted
return "Ok"
})
const start = async () => {
await fastify.listen({ port: 3000 })
console.log('Server running on http://localhost:3000')
}
start()Then call the endpoint, e.g. using curl (assumes app.js is in the same directory):
curl -X POST http://localhost:3000/data -F "[email protected]"
results in
{"statusCode":500,"code":"20","error":"Internal Server Error","message":"This operation was aborted"}
Expected behavior
Expect the signal to not be aborted yet.
Desktop (please complete the following information):
- Node version: v20.18.0
- Package versions: [email protected], [email protected], @fastify/[email protected]
- OS: macOS 14.5 (23F79)
Additional context
It is probably related to fastify/help#866.
The request.raw.closed event is fired as soon as the request payload is consumed, so unfortunately, it is not a reliable way to detect if the request was aborted.
There is probably no easy fix, if there is one at all.