Typescript bindings for R2

[unicomp21]

@kentonv where do I find the typescript bindings for hitting R2 from a worker?

[a-robinson]

They should be right along with all the other workers typescript bindings: https://github.com/cloudflare/workers-types

And it looks like they are if you poke into the giant json file that contains all the types: https://github.com/cloudflare/workers-types/blob/master/src/workers.json

[unicomp21]

@a-robinson is there an efficient way we can "long poll" for changes in a bucket? ie where the long poll will not unlatch until a timeout expires or a change occurs in the r2 bucket?

[Frederik-Baetens]

Hi @unicomp21 . We don't have support for long polling for changes. Your best bet here is probably to route all your uploads/changes to a bucket through a proxy worker that you've deployed. Then that worker can run whatever code you need whenever a request is made.

If you absolutely need polling because you're running an application behind a firewall that doesn't allow inbound requests, you can perhaps look into using websockets with durable objects: https://developers.cloudflare.com/workers/learning/using-durable-objects/#websockets-in-durable-objects.

Alternatively, you can keep track of changes that need to be processed by your polling application in some durable database. You can use Durable Objects for this, or you can use Cloudflare D1, if you've got beta access. Your polling application would then poll either the durable object, or a worker attached to the D1 database.

[unicomp21]

@Frederik-Baetens is there any way to bound worst case clock drift of Date.now() in cloudflare workers? Even a rough estimate would be great.

[Frederik-Baetens]

I think it can get pretty bad in theory, depending on how you structure your code. As part of our spectre mitigations (& other timing side channel mitigations), Date.now() returns the time of the last I/O; it does not advance during code execution.

Source: https://developers.cloudflare.com/workers/runtime-apis/web-standards/

I don't think you should rely on that if timestamp accuracy is critical to your application function correctly.

If you need it to keep track of which new files you've processed, and which ones you haven't, you might be able to achieve that with a version counter. Whenever you start with processing new files, you increase that version counter. After that you store the metadata of which files still need to be processed with a higher version.

[unicomp21]

I like the version/seqno idea. But imho, timestamps might be simpler for me.

The timestamp only being updated during the most recent i/o operation is fine, not a problem. My intention would be to use it in time based bucket schemes. If the clock drift isn't worse than a couple seconds globally, Date.now could be useful. Is there another timestamp elsewhere which might be better?