fix: Pass ctx.props to default handlers

[tewaro]

No description provided.

[github-actions]

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉

[jasnell]

What exactly is the intent here? The PR description needs some explanation and detail. If the idea is to give every invocation it's own unique context, then rather than cloning the entire thing the way this PR does, could it make sense to simply wrap the context in a JS Proxy object for every request and either CoW the underlying context or just intercept mutations so that the original remains unmodified? The per-request props can then be injected via the proxy. Wrapping in a proxy could likely reduce much of the complexity here.

[kentonv]

What exactly is the intent here? The PR description needs some explanation and detail.

The goal of the change is to fix a known bug in which ctx.props is not available for non-class-based entrypoints because such entrypoints have always reused the same ctx object for all invocations. There's a comment on line 1674 describing the issue:

                        // TODO(cleanup): Unfortunately, for non-class-based handlers, we have
                        //   always created only a single `ctx` object and reused it for all
                        //   requests. This is weird and obviously wrong but changing it probably
                        //   requires a compat flag. Until then, connection properties will not be
                        //   available for non-class handlers.

BTW @tewaro we should update that comment to something like:

"Historically, non-class-based handlers reused the same ctx object for all requests. This was an accident, but some Workers depend on it. Newer worker with the unique_ctx_per_invocation will allocate a new ctx for every request."

Wrapping in a proxy could likely reduce much of the complexity here.

That sounds way more complicated to me. This change as-is is really not very complex at all. I don't see what benefit a Proxy would provide here.

[tewaro]

@kentonv how do I force the feature flag on all tests? do I need to modify each one?

[kentonv]

@tewaro I'm just proposing that you temporarily change your code locally to enable the flag by default and make sure the tests actually pass.

[tewaro]

@tewaro I'm just proposing that you temporarily change your code locally to enable the flag by default and make sure the tests actually pass.

I've already done a test where I bump supported-compatibility-date.txt locally, is there anything more I need to do?

[kentonv]

Yes, please add a unit test of some sort, where the test directly enables the flag and verifies that ctx.props is then present when expected. You can perhaps modify or duplicate one of the existing tests for ctx.props in server-test.c++.

[kentonv]

I've already done a test where I bump supported-compatibility-date.txt locally, is there anything more I need to do?

Oh, this doesn't actually accomplish what I asked for earlier.

To be clear, you need to do two things:

1. Include a unit test in the PR itself, which enables the flag and verifies it does what you wanted it to do. In general, you should always do this, in every PR, before you post the PR for review.
2. Unique to this PR: I recommend forcing the flag to be on and running all the existing tests. We would not expect this flag to break any of our tests, so this would help shake out any weird edge cases that we might have missed. Bumping supported-compatibility-date.txt does not cause the flag to be turned on. What I'm suggesting is you temporarily set the flag default value to true, or even just temporarily remove the if statement so that the true branch always runs.