Suddenly all our ctx.waitUntil workers are failing?

We have been using ctx.waitUntil for 2 years already with Cloudflare workers with the basic code sample below. This has always worked without any issues. Suddenly about an hour ago, all our workers with ctx.waitUntil fail with the following error message: "Can't read from request stream after response has been sent." This has never happend before and we haven't changed our code at all . Wondering if something is down with Workers? ctx.waitUntil(executeWebhookWait(request, env, pathName)); finalResponse = { success: true}; return new Response(JSON.stringify(finalResponse), { status: 200, headers: { 'content-type': 'application/json', }, });
async function executeWebhookWait(request: Request, env: Env, pathName: string) {
const content = await request.text(); //DO other STUFFF
}
7 Replies
James
James3d ago
AFAIK, reading request.text() within a waitUntil has always caused an error like that, it just wasn't super obvious in the past before Worker Logs had persistence. Have you made any changes to the worker configuration, compat date, enabled logs, etc. that could impact this? As far as I can tell, there's not been any changes to this functionality in years, and there's no widespread reports.
ddsgadget
ddsgadgetOP3d ago
No we haven't made any changes and this has worked for awhile already. Was working till around 2:30 PM today. And then suddenly stopped working. Interestingly it still works perfectly fine on our development environement and works fine in many other workers. We have done tons of test and its just so strange we can't figure it out. The same exact code worked fine for years already. Works fine on development environment, but just keeps failing in production on one particular worker endpoing out of nowhere. The same code works perfectly fine on another worker which calls everything in the exact same manner
James
James3d ago
Is there a minimal full code example you can share that I could test, that used to work but no longer does? I would expect the code you shared to error, for what it's worth - reading anything from the request inside a waitUntil is generally not a great idea, and you should instead get the info you need while the request context is still active, and then pass that down into whatever you run in waitUntil. You might have been lucky before with timing perhaps and the waitUntil ran before the response was sent? But that's just a theory and very hard to say. For example (pseudo):
const data = await request.text():
ctx.waitUntil(doSomethingWithData(data, env));
const data = await request.text():
ctx.waitUntil(doSomethingWithData(data, env));
ddsgadget
ddsgadgetOP3d ago
yeah, I think we will just refactor the code like you suggest and put the request.text before and test it. It's just so strange that the code worked for years, and then out of nowhere just started erroring. I am thinking there is some sort of race condition between another worker that fires around the same time. thats the only thing I can think of.
James
James3d ago
My guess would be that this was just slow enough before to where your waitUntil was running before the response was sent, and thus request was still available. But Cloudflare are always speeding things up both in software and hardware so it's possible you're just hitting this race condition much more frequently now.
ddsgadget
ddsgadgetOP3d ago
Yeah, that must be it, because this workers runs ridiculously fast now as compared to the past. I'm also thinking of just moving the other endpoint in this particular worker to a separate worker to prevent a race condition. Ok, thanks for your help.
James
James3d ago
Happy to help, hopefully the refactor is a pretty quick and easy one!

Did you find this page helpful?