Skip to content

Conversation

@jack-champagne
Copy link

Issue found when trying to implement an example similar to the one listed in the README. A change in the durable_object macro I believe now makes it so that including wasm_bindgen seems to be required. If not included, a confusing error occurs that is difficult to debug, likely from macro expansion. See error attached below.

error: the `self` argument is only allowed for functions in `impl` blocks.

       If the function is already in an `impl` block, did you perhaps forget to add `#[wasm_bindgen]` to the `impl` block?
 --> src/lib.rs:3:1
  |
3 | #[durable_object]
  | ^^^^^^^^^^^^^^^^^
  |
  = note: this error originates in the attribute macro `durable_object` (in Nightly builds, run with -Z macro-backtrace for more info)

error: recursion limit reached while expanding `#[derive]`
 --> src/lib.rs:3:1
  |
3 | #[durable_object]
  | ^^^^^^^^^^^^^^^^^
  |
  = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`durable-object-demo`)
  = note: this error originates in the attribute macro `wasm_bindgen` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `durable-object-demo` (lib) due to 2 previous errors

@guybedford
Copy link
Collaborator

I believe I fixed this in #816, released in worker 0.6.4. Are you seeing this in that version or above or an earlier version?

@jack-champagne
Copy link
Author

I was seeing this on 0.6.7 but I can check in 0.6.4 as well. For reference, here is my full src/lib.rs

on worker 0.6.7:

use worker::{durable_object, event, wasm_bindgen, Env, Request, Response, Result, State};

type User = String;
type Message = String;

#[durable_object]
pub struct Chatroom {
    users: Vec<User>,
    messages: Vec<Message>,
    state: State,
    env: Env, // access `Env` across requests, use inside `fetch`
}
impl DurableObject for Chatroom {
    fn new(state: State, env: Env) -> Self {
        Self {
            users: vec![],
            messages: vec![],
            state: state,
            env,
        }
    }
    async fn fetch(&self, _req: Request) -> Result<Response> {
        // do some work when a worker makes a request to this DO
        Response::ok(&format!("{} active users.", self.users.len()))
    }
}

#[event(fetch)]
async fn fetch(req: Request, env: Env, _ctx: worker::Context) -> Result<Response> {
    let ns = env.durable_object("CHATROOM")?;
    let stub = ns.id_from_name("chatroom-1")?.get_stub()?;
    stub.fetch_with_request(req).await
}

@jack-champagne
Copy link
Author

Same error with same code but using worker v0.6.4:

worker 0.6.4 (same code) error:

error: the `self` argument is only allowed for functions in `impl` blocks.

       If the function is already in an `impl` block, did you perhaps forget to add `#[wasm_bindgen]` to the `impl` block?
 --> src/lib.rs:6:1
  |
6 | #[durable_object]
  | ^^^^^^^^^^^^^^^^^
  |
  = note: this error originates in the attribute macro `durable_object` (in Nightly builds, run with -Z macro-backtrace for more info)

error: recursion limit reached while expanding `#[derive]`
 --> src/lib.rs:6:1
  |
6 | #[durable_object]
  | ^^^^^^^^^^^^^^^^^
  |
  = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`durable_object_demo`)
  = note: this error originates in the attribute macro `wasm_bindgen` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `durable-object-demo` (lib) due to 2 previous errors

just a quick check to make sure I'm using the right version in my Cargo.lock

cargo tree | grep -e "worker"

gives:

├── worker v0.6.4
│   ├── worker-kv v0.9.0
│   ├── worker-macros v0.6.4 (proc-macro)
│   │   └── worker-sys v0.6.7
│   └── worker-sys v0.6.7 (*)
└── worker-macros v0.6.4 (proc-macro) (*)

@guybedford
Copy link
Collaborator

I just copied and pasted your exact code example into a test project with this Cargo.toml:

[package]
name = "rustworker"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "=0.2.105"
worker = { version = "0.6.7" }
worker-macros = { version = "0.6.7" }

and this wrangler.toml

name = "rustworker"
main = "build/worker/shim.mjs"
compatibility_date = "2025-11-01"

[build]
command = "cargo install -q worker-build && worker-build --release"

and it works fine for me via npx wrangler dev.

Let me know if that works for you, or please share replication instructions further.

on new project creation, if we use the #[durable_object] attribute
the macro expansion fails because wasm-bindgen must be included as
a dependency.
@jack-champagne jack-champagne force-pushed the fix/durable-objects-docs branch from cc44a54 to a281b98 Compare November 11, 2025 19:39
@jack-champagne
Copy link
Author

jack-champagne commented Nov 11, 2025

Thanks, just checked on v0.6.4 and v0.6.7 with the updated Project.toml -

Looks like it's working for both of those versions without use worker::wasm_bindgen anymore which is good. I think updating the generated project from cargo generate might be helpful for new users trying this stuff out - or alternatively finding a way for the macro to give a bit more info on whats gone wrong.

I've pushed a new commit to this pr that just updates the templates, not sure if this is the direction you'd want to take.

@jack-champagne
Copy link
Author

Since I was able to reproduce locally, if my changes to the templates are not warranted this pull request can be closed.

@guybedford
Copy link
Collaborator

It looks like #816 isn't quite right if this is needed.

I think that macro fix needs to be changed to use worker::wasm_bindgen.

@jack-champagne
Copy link
Author

jack-champagne commented Nov 13, 2025

I think you're right, I remember viewing this PR while I was trying to figure out what was wrong. I could not tell because I don't have a ton of experience with debugging rust macros/rust macros in general. I can give it a go

@guybedford
Copy link
Collaborator

Thanks for your feedback and thought on this - I've posted #869 which should fix this but please let me know if you see any further issues.

@jack-champagne
Copy link
Author

Thanks, this change fixed the issue on the latest version. Closing this PR because of change in #869

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants