Version metadata lacks timestamp field
I'm trying to get the deployment date of my worker from inside the worker so it can handle the
if-modified-since header appropriately. But the binding gives me an object which lacks the timestamp field described in the documentation at:
https://developers.cloudflare.com/workers/runtime-apis/bindings/version-metadata/Cloudflare Docs
Version metadata binding · Cloudflare Workers docs
Exposes Worker version metadata (versionID and versionTag). These fields can be added to events emitted from the Worker to send to downstream observability systems.
16 Replies
and then in index.ts I tried
console.log(env.CF_VERSION_METADATA); and it has only the two fields. And wrangler types also only generated the two fields in worker-configuration.d.ts
Huh. That's all very different from what I have. I didn't expect a number field, I did expect a tag field, and I didn't expect it to be inside of another object giving it a name. Where does all this output come from?
Could it have been recently removed? I wondered if it had been recently added except I saw old pages linking to it from last year so it has definitely existed in the past.nope definitely didn't remove it
i'm actually using script metadata here so a bit diff, just deployed with version metadata and still see it: https://test.walshydev.workers.dev/
?link-account
Please use the /link-account command to authenticate with your Cloudflare account and link it to your Discord user. This helps Cloudflare employees access your details more quickly and provide support. It also makes future support requests easier, since your account will already be linked.
can you link and tell me the worker name?
Uh-oh. This isn't going to look very professional.
Oh I'm green now.
https://yellow-dust-ecb5.sh1.workers.dev/
It looks ok to me :thonk:
Ok, first how do you make that query?
I was working locally. Is it just an omission in miniflare?
oh yeah local probably doesn't have it
wouldn't surprise me if that was a bug
internal magic 🪄
That's a bit of a recurring thing.
wrangler types reverts changes to worker-configuration, and then the settings get deleted off the deployment because they've been removed from the config.
This time it didn't generate it in the first place, but even if I put it in manually it looks like it'll revert next time I update types.i'm not sure how wrangler types is generating it
if you file an issue on workers-sdk they can get a fix up for it - https://github.com/cloudflare/workers-sdk/issues
It generates a binding for id and tag but missing timestamp.
https://github.com/cloudflare/workers-sdk/blob/f00775126b7de00bf77c12e5533ae3b2e380406e/packages/wrangler/src/type-generation/index.ts#L508
yeah can see the bug here
if you haven't by tomorrow, i'll get it on the teams radar
https://github.com/cloudflare/workers-sdk/issues/8989
Hope that makes sense. Writing the whole thing on my phone.
GitHub
Wrangler doesn't correctly generate type for worker version metadat...
Adding the binding to wrangler.jsonc as instructed in docs generates only a partial type, with id and tag but no timestamp, in worker-configuration.d.ts. I could edit it in manually but the next ru...
Yep that's good - thank you!
I'll just hack that in locally for now, then. Hopefully by the time I rebuild the types it'll already be there.