Generalize record-replay: serialize closures passed to any RPC method

[ryanrasti]

<stub>.map(fn) already records fn locally, emits a ["remap", …] instruction, and replays it on the receiver. This generalizes the mechanism so any user-defined method on an RpcTarget can accept callbacks that serialize the same way.

Motivation: I'm building typegres which uses capnweb to expose a capability-based query builder:

users.where(({ users })=>users.id["="](1n)).select(({ users })=>({id: users.id,name: users.name.upper()})).execute();

The callbacks should be interpreted server-side (not exported as a stub and sent back to client).

Key design decisions

1. Backward compatibility: Plain functions passed over RPC today are exported as stubs (pass-by-reference). To keep that unchanged, the draft only routes functions through record-replay when they're passed inside a .map() callback — where creating a new stub is already forbidden. (No new opt-in flags needed).
2. Sharing between map and general closures: I chose to re-use the most code possible but maintain distinct wire formats for remap and closure.

Potential follow-ons (not in this PR):

1. Sync replay for closures -- the receiver's replay fn currently returns a Promise because RpcPayload.deliverResolve always wraps in one, even when nothing needs awaiting. Async closures are already rejected at serialize time.

• Why this matters: Typegres's query builder is synchronous -- without sync replay, every callback-taking method has to become async, infecting the call chain.

2. Stub identity preservation: independent of closures: round-tripping a stub back to its owner currently yields a proxy, not the raw target.

• Why this matters: server may need to do things like validate the type of the object, access non-exposed fields, etc. which are impossible to do if its own object is wrapped behind a stub

(Opening as a draft to get your read on the design -- happy to rework anything.)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 43dc308

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

[github-actions]

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

[ryanrasti]

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

[kentonv]

Hmm. Restricting this to only work inside a .map() is an interesting way to sidestep the question of which calls should accept pass-by-value closures. But could you give me some more complete examples of how you see this looking in practice? Your example in the description doesn't include the surrounding .map().

[ryanrasti]

Restricting this to only work inside a .map() is an interesting way to sidestep the question of which calls should accept pass-by-value closures. But could you give me some more complete examples of how you see this looking in practice? Your example in the description doesn't include the surrounding .map().

Sure thing. And yes .map() is the boundary that activates closure serialization. It's potentially a nice fit because the body of map is pass-by-value by definition:

// Table definitions:classPostextendsRpcTarget{getid(){returnthis.column('id')}getuserId(){returnthis.column('user_id')}getcontent(){returnthis.column('content')}}classUserextendsRpcTarget{getid(){returnthis.column('id')}posts(){returnPost.from().where(({posts})=>posts.userId['='](this.id))}}// Main stub:classApiextendsRpcTarget{userForToken(token: string){constuserId=validateToken(token)returnUser.from().where(({users})=>users.id['='](userId))}db(): Database{ ... }}// Actual usage:constgetNumPosts=(api: RpcStub<Api>)=>{consttoken=tokenFromContext(...)constresults=api.map(_=>api.userForToken(token).select(({users})=>({id: users.id,numPosts: users.posts().groupBy().select(({posts})=>posts.id.count())})).execute(api.db()))returnresults[0]?.numPosts??0}

The shape I'm envisioning: wrap the entire query once in a map() (or something else that signals pass-by-value), and write the callbacks naturally inside.

[ndisidore]

I see you're still pushing here: holler when you want another set of eyes!