workers-sdk
workers-sdk copied to clipboard
Support cron triggers using preview and dev
💡 Feature request
Describe the feature
Currently, there is no way to test scheduled jobs, since we can't fire a scheduled during development. I suggest adding support of "cron triggers testing" for wrangler dev or wrangler preview, which speeds up the development and testing.
Possible methods of triggering a cron job during development:
- For
wrangler dev, wrangler creates a special route (path) during development, and developers can trigger a job by sending a request to the route, eg:GET http://127.0.0.1:8787/__crons/:cronExpression - For
wrangler preview, aTest Triggerstab is available for developers to trigger a cron job.
Describe the alternatives
The current work around for this issue is to simply deploy the worker to production.
Or add the code I want to test to the fetch event handler, which is really inconvenient:
addEventListener('scheduled', (event) => {
event.waitUntil(scheduledJob(event))
});
addEventListener('fetch', (event) => {
event.respondWith(scheduledJob(event))
})
const scheduledJob = (event) => {
// Job
}
Thanks.
Thanks for making this issue! This is definitely something we need to support.
In the interim, a simple workaround would be to call a mock scheduled event from a fetch handler. Not nice, but it can get the job done for you if you need it today.
Cloudflare recently released miniflare, which supports cron trigger testing. If anyone wants to test cron triggers at the moment, you may refer this link https://miniflare.dev/scheduled.html
Of cause, cron trigger support for wrangler dev/wrangler preview would also be appreciated
Copy pasting from https://github.com/cloudflare/wrangler2/pull/738#issuecomment-1084590138, where we're landing support for local mode soon.
- We've resisted adding miniflare specific features that don't have edge equivalents, but this seems like a good exception to make.
- That said, let's consider this experimental, and not make too much noise about it for now. This will definitely change in the future.
- We could probably make this work on the edge too. For module workers, we could wrap the worker in a facade that exposes a route that triggers the
default.scheduledexport. For service workers, we'd have to overrideaddEventListenerand wrap the fetch handler with our own thing.