add Props generic to ExportedHandler for ExecutionContext

[deathbyknowledge]

Adds a Props type parameter to the ExportedHandler types for ExecutionContext.

More context cloudflare/agents#501

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[deathbyknowledge]

I have read the CLA Document and I hereby sign the CLA

[codspeed-hq]

Merging this PR will not alter performance

✅ 70 untouched benchmarks
⏩ 129 skipped benchmarks¹

---

_{Comparing deathbyknowledge:props-type-parameter (fe15f09) with main (1e9fd8e)}

Footnotes

1. 129 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[kentonv]

FWIW, while this change is fine, the last time someone proposed it, we figured out that they were using props in a way that wasn't intended.

ctx.props is not intended to be assigned by the application. It's intended to be filled in by the platform based on the binding used to invoke the entrypoint.

workers-auth-provider cheats a bit, but only because semantically I was trying to emulate what would happen if we had OAuth more built into the platform. It breaks the letter but keeps the spirit of the rule.

People should not, however, be using ctx.props as a place to stash their own data related to the request. They should use their own separate object for that. Or you could always assign some arbitrary property like ctx.mySpecialRequestData -- this is no worse than assigning into ctx.props.

[jasnell]

I'm not arguing for it one way or the other ... just asking ... should we consider making props effectively read-only by either (a) freezing it or (b) wrapping it such that assignments from user code are ignored?

[kentonv]

@jasnell nah. Most JS APIs allow you to assign random properties on them even though it's probably not a great idea. No real reason to block it here, but also no reason to go out of our way to support it better.

[deathbyknowledge]

ctx.mySpecialRequestData

Ack. We're currently using ctx.props in the Agents SDK but we'll explore declaring our own property on ctx directly.

Are we OK merging the changes here then?

[kentonv]

Are we OK merging the changes here then?

CI looks pretty red. We'd need to fix that.

EDIT: Some failures looked spurious so I clicked to re-run.

[deathbyknowledge]

Ah sorry I thought the snapshots were generated on CI. Fixed.
@dom96 the internal-build job fails because I'm not a member of the org, do you mind starting it for me please?

[dom96]

Done. Though it seems it failed with the same error. You do seem to be a member of the Cloudflare org though.

@ketanhwr any ideas what might be going wrong here?

[deathbyknowledge]

Hey @dom96, I was a "private" member of the org, I've updated it to public, maybe that does it. Do you mind kicking off another run?

[deathbyknowledge]

Could someone lend a hand on what's wrong with the errors in CI? I'm not sure how my changes are breaking those

[dom96]

They look like flakes to me, I re-ran them, let's see if that helps