Allow routing ctx props to Server

[deathbyknowledge]

Since we now can have props in ExecutionContext when using an OAuthProvider, we could optionally route them to the Server and make them available as a parameter in onStart.

The opt-in is fairly straightforward, if you want to make sure your Server tracks props, you'd use:

asyncfetch(request: Request,env: Env,ctx: ExecutionContext): Promise<Response>{// ...constserver=awaitgetServerByName(env.MY_SERVER,'default',{props: ctx.props});// Alternativelyconstresponse=awaitroutePartykitRequest(request,env,{ ...otherOptions,props: ctx.props})// ...}

A class that extends Server can make sure the props are available during the entire lifecycle of the DO by using:

 props?: Props;asynconStart(props?: Props){// If onStart was passed props, save them to storageif(props){awaitthis.ctx.storage.put("props",props);}this.props=awaitthis.ctx.storage.get("props");// Rest of your initialization logic...}

Related to cloudflare/agents#415, as it props were only implemented in McpServer

[changeset-bot]

⚠️ No Changeset found

Latest commit: ffb92ce

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[threepointone]

hmm one problem is that onStart is called before an alarm on a new DO, and props won't be available there. it's... fine. they'll have to implement it in app layer anyway (at least for now)