scheduled event failed

[theowenyoung]

lib.rs:

mod utils;
use worker::*;
// could not find `Schedule` in `worker`rustc(E0433)
#[event(scheduled)]
pub async fn main(ty: String, schedule: u64, cron: String) -> Result<()> {
    println!("test");
    Ok(())
}

Is there something I missed?

[nilslice]

No, you found some work in progress that is not supported yet. Sorry about that!

[theowenyoung]

Ok, I'll wait it until production!

[mlafeldt]

Also stumbled on this today. So it's not possible to handle cron events with workers-rs right now?

[nilslice]

@mlafeldt - sorry about that. correct, as of now you can only use the fetch event. It shouldn't be a ton of work to get scheduled events working, but I just don't have the bandwidth at the moment to get it started. I'd be happy to point you in the right direction though if you're interested in taking a look at implementing it.

[mlafeldt]

Sure, a couple of pointers would be nice! I'm new to Cloudflare Workers (after having used Lambda for many years).

[nilslice]

@mlafeldt - the event macro, which I'm sure you've come across, translates the worker crate types (convenience types over "raw" FFI bindings to Workers JS runtime types).

This macro currently has a broken implementation for scheduled, as you can see here: https://github.com/cloudflare/workers-rs/blob/main/worker-macros/src/event.rs#L84 (leftover from early experimentation).

The bulk of the work is to ensure the args passed to the handler function (the equivalent of fetch in the Fetch event) match with what the JS glue code will pass to the wasm. This needs to conform to the ScheduledEvent API: https://developers.cloudflare.com/workers/runtime-apis/scheduled-event

That JS -> wasm handoff is exposed in generated JS code (https://github.com/cloudflare/workers-rs/blob/main/worker-build/src/main.rs#L133-L140), and currently is only set up to support fetch as the import. I'm not sure how to best handle adding another function here.. it could be undefined if the user doesn't use the scheduled event, maybe that's ok with a runtime check.. not sure.

The best way to start this would be to follow what the fetch path does and fill in the gaps - sorry that's not a great bit of detail, and am happy to answer questions along the way. If you don't end up working on this, no worries -- I just want to be transparent that it's not the top priority at the moment for us to implement internally and I don't have a good estimate yet as to when the work would be picked up.

[mlafeldt]

Thanks for the explanation, @nilslice. We don't have a direct need for cron events right now, so it's not a priority at work. I or someone else might still be able to take a stab at it later.

[zebp]

Fixed by #104