feat: trigger scheduled events from fetch events for testing #1722
Conversation
🦋 Changeset detectedLatest commit: e93a994 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.developers.workers.dev/runs/2912204504/npm-package-wrangler-1722You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.developers.workers.dev/prs/1722/npm-package-wrangler-1722Or you can use npx https://prerelease-registry.developers.workers.dev/runs/2912204504/npm-package-wrangler-1722 dev path/to/script.js |
Codecov Report
@@ Coverage Diff @@
## main #1722 +/- ##
==========================================
- Coverage 82.00% 80.53% -1.47%
==========================================
Files 89 90 +1
Lines 5884 6135 +251
Branches 1509 1586 +77
==========================================
+ Hits 4825 4941 +116
- Misses 1059 1194 +135
|
cameron-robey
requested review from
threepointone and
petebacondarwin
as code owners
cameron-robey
changed the title
| export let swAddEventListener = (event, listener) => { | ||
| if (event === "fetch") { | ||
| globalThis.__inner_sw_fetch_listeners__.push(listener); | ||
| } else if (event === "scheduled") { | ||
| globalThis.__inner_sw_scheduled_listeners__.push(listener); | ||
| } else { | ||
| globalThis.addEventListener(event, listener); | ||
| } | ||
| }; |
There was a problem hiding this comment.
Workers global scopes are instances of ServiceWorkerGlobalScope which inherits from EventTarget. This provides the addEventListener method, along with removeEventListener and dispatchEvent. There are quite a few subtleties when using EventTargets. For example, listener may be a function, or an object of the form { handleEvent(event) { ... } }. Additionally, calling FetchEvent#respondWith() should implicitly call Event#stopImmediatePropagation(), meaning further event listeners aren't called. I'll talk to offline about a slightly different approach that means you don't have to implement all of this logic yourself.
Nothing in the runtime prevents access to cdn-cgi, it's another edge service that runs before the runtime that explicitly handles it. |
|
How would be the URL when the entry point of a worker is not just |
|
Closing in favour of #1815 |
/___scheduledCurrently only switches on with an environment variable
FETCH_TRIGGER_CRON=true- we need to think about how we trigger this.The advantage of the way that Miniflare implements this is that
/cdn-cgi/mfis never going to accessible to a worker anyway, and (probably) never will be used internally so there is no chance of it overwriting an actual route.The need therefore is to find a url that will pretty much never be used so that we can use it for testing cron workers - suggested here is
/___scheduled. If it is never used then we could enable this functionality all the time for wrangler dev, rather than needing to enable with a command line flag.Closes: #570
To do before release:
/___scheduled?cron=*+*+*+*+*A few other notes:
/cdn-cgi/mf/scheduledwhich we cannot access as/cdn-cgiis not accessible when running on the edge. Once this has been landed we should migrate miniflare to using the same endpoint as here./cdn-cgiso it may need to migrate anyway