oh the Past Events is under Logs not under Triggers like the docs say....

but anyways all it just says is "Success"

okay I think the problem is I wasn't returning from

refreshAccessToken

so the worker was killed before it completed. it works fine locally though, so maybe the behavior should be changed so it is similar

waitUntil will wait for refreshAccessToken’s promise to resolve

If there’s any async work in refreshAccessToken that you didn’t await though, it could resolve before that finishes

yeah that must be what happened

it worked locally though, would be nice for it to have failed locally as well

I have a cron trigger that has been running fine for a year, but some days ago it stopped working Is it possible to see more details about the error anywhere?

Stream the logs & wait for the next execution, you'll get the logs from that

Past logs aren't recorded, you'd need to use Logpush for that (paid plan)

I tried the log stream and waited for 5 minutes, but nothing showed up (trigger is every 1 minute)

Wait, I tried the stream again and it shows in the log now 🙂

All good

Tried workers together with d1 yesterday. (First time using both) loving it so far

Random question, would it be unreasonable to rely on hash-mangled filenames from __STATIC_CONTENT_MANIFEST? I'd like to rewrite referenced static resources with a hash to never have to worry about client side cache invalidation, and all the work has effectively been done for me, which is amazing. But I don't know if this falls on the "undocumented implementation detail" end of things

That’s basically what https://github.com/cloudflare/kv-asset-handler does. So I’d just recommend using that honestly

Thanks, yeah I'm effectively doing the same thing with my own code (not using sites, just a plain worker). I'll look into switching over

Yeah, mapRequestToAsset would do it, but I'd have to jump throught hoops since it takes a Request and I'm doing some other funny things with paths; really just want a string->string function (which I already have, just didn't know how reliable it will be long term). Would be nice if there was some guarantee that wrangler would upload static assets the way it does right now, and __STATIC_CONTENT_MANIFEST could become public api? Nbd either way, worse case I just so my own static asset uploading instead of relying on wrangler's [site]/bucket

is it bad practice to use the cache as a key value store? (refering to

const cache = await caches.open('...')

)

It’s risky since the cache isn’t promised to actually store things. Only best effort.

You could store something, then try to fetch it right after, and it’s not there.

but what's then even the point of using the cache api?

i know it's not guaranteed that the item is stored for the time it's expected to, but that it's not stored at all is new to me

it usually will be stored

you can use it as a key value store as long as you're okay with it being best effort and not counting on it to be reliable.

I think that might have been a slight exaggeration. There are no guarantees whatsoever, so it could be gone almost immediately

Usually it will work, but yeah just make sure to handle the edge cases

How do I define an array that's optional in

requestBody

for itty-router-openapi?