Cron schedules can take up to 15 minutes to start working, if that's a new one.
Cron schedules can take up to 15 minutes to start working, if that's a new one.
Iits been 5 hours
Ianyone?
Iplease help
Cbecause one's the default workers.dev route you can't delete, only disable, and the other one is a custom route you added that you can delete?
CIs it going over an existing origin? If not, did you create a DNS Record for it?
If you're using routes, and you don't have an existing website/origin at that hostname, you'll need to create an originless dns record.
I would recommend using Worker Custom Domains though, if there is no existing origin. They take care of the dns record creation for you, issue you a cert, and just work
If you're using routes, and you don't have an existing website/origin at that hostname, you'll need to create an originless dns record.
I would recommend using Worker Custom Domains though, if there is no existing origin. They take care of the dns record creation for you, issue you a cert, and just work
CIt may be worth noting: if your route is
Otherwise, that's strange. You're watching tail and not seeing it be executed?
example.com/example.com/* to match all paths.Otherwise, that's strange. You're watching tail and not seeing it be executed?
Cwell at least it was something simple
PHow to ALTER column type?
ALTER TABLE SUBS ALTER COLUMN ID TYPE TEXT; this code return near "ALTER": syntax error not working
CI don't believe sqlite supports changing the column type
DHas anyone successfully used the stackblitz code for the direct creator upload? I
MI have a super simple stub worker that does nothing at all (literally) and fails to upload as soon as I add an
import { AwsClient } from "aws4fetch" at the top with this error: { code: 10068, message: "The uploaded script has no registered event handlers." } ... I have another more complicated worker (provided by denoflare example) which does successfully publish fine and as far as I can tell it doesn't register any event handlers... what am I missing?
KHow are you uploading it, Wrangler?
Mdenoflare push
M@kian it's actually a modified version of your s3-to-r2 script... and which actually tried to publish your unmodified version of the script and still got the same error... and a completely stripped back to almost nothing version... to find that it is the aws4fetch import that breaks things
KI’m not too familiar with Denoflare, but it sounds like it isn’t telling the API that it’s a Module Worker rather than a Service Worker
KThat or the bundled output is a little wrong
Mthis is the entire stripped back script... it deploys successfully without the aws4fetch import...
MI wonder the build is using the wrong cjs version instead of the esm version of aws4fetch
MI tried switching to wrangler and the stripped back script publishes... and your unmodified version works... but the modified version is importing some denoflare code from a URL
import r2PresignedUrlWorker from "https://raw.githubusercontent.com/skymethod/denoflare/v0.5.11/examples/r2-presigned-url-worker/worker.ts"; which wrangler complains about: Uncaught Error: No such moduleKCloudflare doesn't support URL imports, that's just a Deno thing
Mcan I get wrangler to bundle it before publish?
M(like denoflare push does)... but it seems denoflare push is building a bundle.js which is somehow messing up the registered event handler (fetch)... but I can't find the bundle.js to take a look at what it's doing...
KWrangler wouldn't bundle URL imports, it just uses esbuild
KMy code doesn't use Deno(flare) at all so it would work as-is with Wrangler
Myes your code works as is with wrangler
Mbut we are trying to combine your worker with the denoflare r2-presigned-url-worker example
DCan anyone help me with the TUS direct creator upload?
DI’ve read the documentation but I can’t figure out why it’s not working
JSimply install them with npm and import them as you would normally.
Do note that axios won’t work natively though - it uses things like
I believe in the case of axios there’s a way to make it use
Do note that axios won’t work natively though - it uses things like
http which don’t don’t exist in workers. Workers aren’t node.js and although they’re slowly getting a lot more nodejs APIs for compat, they don’t have them all yet.I believe in the case of axios there’s a way to make it use
fetch
MThis is probably a really silly question but is there a simple way to group
itty-routerjs ?KLike grouping the
.get(..., ...) part or just the handlers?MFor now, just the
.get()I feel like there's a better way to organize routing then just cramming it into the entry point js. Google has failed me thusfar.
Kyou can nest routers
Kso you can have a router that handles everything under
/api/pages/Kand import that in main.js for
/api/pages/*MAhhh, I see. Ok, I'm going to give that a whirl. Thanks @kian
Ware you using
awaitasync