Cloudflare worker context persists between requests?

[fallen depot]

I don’t think Context even should be console loggable, but it’s API-surface shouldn’t change between requests

And also, there shouldn’t ever be extras there either

[carmine epoch]

I'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.

[fallen depot]

Yeah, but even if it is loggable, it isn’t supposed to be visibly different between requests

[carmine epoch]

My context has fields like "auth_user" which should be different between requests if requests are done by different users

[fallen depot]

Must be some code doing weird stuff with the context then

As in, you aren’t supposed to modify it at all

[carmine epoch]

Interesting! 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.

[fallen depot]

Funnily 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

[carmine epoch]

Got 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.

[fallen depot]

I think it is more that, while you can do this if you want to, they never tested persistence of random data across multiple requests

So it is an unintended issue

[carmine epoch]

Where 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.

[fallen depot]

Routers usually have a utility for that. Hono has set/get

[carmine epoch]

Looking 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!

[safe raft]

In 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.