workers-rs: [BUG] Version 0.0.10 causes `wrangler publish` failure

Is there an existing issue for this?

I have searched the existing issues

What version of `workers-rs` are you using?

0.0.10

Describe the bug

With workers-rs 0.0.10, deploying u32i64/signalupdates-bot (e.g. at this revision) fails with the following error:

 ⛅️ wrangler 2.0.15 
--------------------
Running custom build: cargo install worker-build && worker-build --release
    Updating crates.io index
     Ignored package `worker-build v0.0.6` is already installed, use --force to override
[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
    Finished release [optimized] target(s) in 0.07s
[INFO]: ⬇️  Installing wasm-bindgen...
[INFO]: Optimizing wasm binaries with `wasm-opt`...
[INFO]: Optional fields missing from Cargo.toml: 'description', 'repository', and 'license'. These are not necessary, but recommended
[INFO]: ✨   Done in 1.24s
[INFO]: 📦   Your wasm pkg is ready to publish at [redacted path]/signalupdates-bot/build.
Your worker has access to the following bindings:
- KV Namespaces:
  - STATE: [redacted namespace id]

✘ [ERROR] A request to the Cloudflare API (/accounts/[redacted account id]/workers/scripts/signalupdates-bot) failed.

  Uncaught TypeError: Cannot read properties of undefined (reading
  'memory')
    at line 0
   [code: 10021]

  
  If you think this is a bug, please open an issue at:
  https://github.com/cloudflare/wrangler2/issues/new/choose

Deploying the same worker with workers-rs 0.0.9 (e.g. at this revision) is successful (hence I’m reporting this here instead of cloudflare/wrangler2 as the error suggests).

The wrangler.toml file is identical to wrangler.example.toml, except the account and KV namespace IDs are specified instead of ....

Steps To Reproduce

No response

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 3
Comments: 18 (7 by maintainers)

Commits related to this issue

Implement workaround for worker-build bug This is needed in order to deploy Daphne-Worker. See https://github.com/cloudflare/workers-rs/issues/204. — committed to cloudflare/daphne by cjpatton 2 years ago
Implement workaround for worker-build bug This is needed in order to deploy Daphne-Worker. See https://github.com/cloudflare/workers-rs/issues/204. — committed to cloudflare/daphne by cjpatton 2 years ago

Most upvoted comments

I have the same issue when running wrangler dev as well

tsunrise on Jun 25, 2022

I’ve identified a fix but it’s currently blocked on https://github.com/swc-project/swc/issues/4864. This puts us in a weird place where we ideally want to keep using SWC, but it looks like it’ll be a while until it’s fixed. Whereas esbuild doesn’t suffer from this behavior but would require either esbuild or npm on the user’s path.

I also identified a hacky fix that would fix this issue, but another one similar to this could pop up later whenever wasm-bindgen makes changes to the generated JS. I think that’s what we’ll have to go with for now.

zebp on Jun 24, 2022

Hmmm, it seems to be that wasm-bindgen doesn’t always generate the same definition of cachedFloat64Memory0 and similar variables causing the modification we do to the generated JS glue after the fact to break. Building worker-sandbox has these set to null whereas your worker assigns them to new Float64Array(wasm.memory.buffer).

worker-build currently works under the assumption that nothing in the JS glue tries to access the wasm variable until the WASM is actually invoked, but apparently that isn’t always the case. I’ll work on a fix but you should probably roll back to 0.0.9 and pin your worker-build install command to the previous version.

zebp on Jun 23, 2022