Cloudflare worker context persists between requests?
Original message was deleted
HI don’t think Context even should be console loggable, but it’s API-surface shouldn’t change between requests
HAnd also, there shouldn’t ever be extras there either
RI'm only logging this in my local dev env. It's definitely loggable. I'm using https://github.com/cloudflare/itty-router-openapi, which can have other vars in the fetch.
HYeah, but even if it is loggable, it isn’t supposed to be visibly different between requests
RMy context has fields like "auth_user" which should be different between requests if requests are done by different users
HMust be some code doing weird stuff with the context then
HAs in, you aren’t supposed to modify it at all
RInteresting! Is it anywhere in the docs that context should not be modified by any route handlers? I thought that context just carries request context, including things that we want to keep there for duration of request.
HFunnily enough, I don’t think so. I know that the two methods on it are tied to the request context, so maybe the way it is tied to a specific request only applies to those, and not any other data you shim onto it
RGot it. Will look for it in the docs. If context is not to be modified in this way, I would hope the docs would clearly state.
HI think it is more that, while you can do this if you want to, they never tested persistence of random data across multiple requests
HSo it is an unintended issue
RWhere would you keep data between different handlers that might be processing the same request? (e.g. the first handler authenticates, second one has business logic conditioned on authentication results). First handler's gotta pass state to second handler.
HUltrafast web framework for Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, Lagon, Node.js, and others. Fast, but not only fast.
RLooking at itty docs - looks like they put it in request rather than context: https://itty.dev/itty-router/middleware... will need to do some more digging. Thx for taking the time!
KIn general within itty, we use the request as the carrier agent for context because it’s the only guaranteed argument in a route handler. That said, assuming you pass more args to router.handle, each of those passes into every handler (in the same order), so you can use any of those as a transport.
KLike in Workers, we tend to pass request, env, context… so you could use any of those (or add your own dedicated state/context arg)
