workers-rs Feat: Marked SendFuture and SendWrapper as unsafe types

Moved away from general unsafe impls to better communicate the usage style of SendFutures, removed unneeded Sync + Send impls from the Ai Module (Can instead implement SendWrapper).

This will probably constitute an api breakage and should (maybe?) go in the next release if accepted.

Jul 18 '25 15:07 parzivale

CI seems to be failing here after rebase.

Agreed this is the better user experience, would be happy to land it for the next major release after the current patch release.

Jul 24 '25 23:07 guybedford

@guybedford should be good to merge now

Sep 25 '25 20:09 parzivale

Hey what is missing from this for it to be mergeable?

Oct 16 '25 19:10 parzivale

I posted https://github.com/cloudflare/workers-rs/pull/861 here which just removes send entirely. Putting this one out there as a stake to question why we need this at all. At the very least I would have expected a failing test. Feedback and thoughts very much welcome.

Oct 30 '25 19:10 guybedford

As you mentioned in #861 this is due to Axum requiring send for it's handlers

Oct 30 '25 19:10 parzivale

Plus a lot of crates require send, I believe it is useful to expose a sensible default for implementing unsafe send

Oct 30 '25 19:10 parzivale

Ok, so just to get my head clear on the framing - SendFuture and SendWrapper are effectively wasm-bindgen helpers to allow single threaded apps to treat JS types as send.

Then working through still from fundamentals - why do we need to wrap the whole future? Can't we just make all JS types implement Send?

Oct 30 '25 20:10 guybedford

What if we just had a wasm bindgen flag like wasm-bindgen --unsafe-single-threaded-send that made all JS types unsafe send?

Oct 30 '25 20:10 guybedford

Hmm I mean it could work, you would probably would want both a crate feature and a cli feature as if threading ever came to wasm you would have to deactivate all threading code. Tbh Im nowhere near qualified enough to fully answer this

Oct 30 '25 20:10 parzivale

wasm-bindgen supports threading fine - so we would not allow the flag to exist alongside any use of threading.

Let me see if I can hack something together, will post back here shortly.

Oct 30 '25 20:10 guybedford

Yeah it all seems to work, implemented https://github.com/wasm-bindgen/wasm-bindgen/pull/4770 and applied this to https://github.com/cloudflare/workers-rs/pull/861. Further feedback welcome.

Oct 30 '25 21:10 guybedford

Yep I think yours is the better solution, unless workerd ever plans to move to a threaded execution model this makes everything considerably simpler.

Oct 31 '25 11:10 parzivale

Ill keep this pr open while https://github.com/wasm-bindgen/wasm-bindgen/pull/4770 is open

Oct 31 '25 11:10 parzivale