https://discord.cloudflare.com logo
Join Discord
Powered by
# r2
  • j
    have you tried it yourself against the real service? here's a quick way to repro it using the aws cli: 
    aws s3api delete-objects --bucket <bucket> --endpoint-url https://<account-id>.r2.cloudflarestorage.com --delete "Objects=[{Key=a}],Quiet=true" --profile <r2-profile-name>
    You will see the deleted keys returned
  • v
    I have not tried the aws CLI. I just ran the JS SDK and the tests pass. It's on our backlog to dig in but it's going to be a low-priority thing because there's no egress cost.
  • j
    you probably should run tests with the aws cli, very widely used
  • j
    somewhat related to delete-objects, any plans on having the ability to delete multiple keys with one call from the worker binding interface?
  • v
    I don't disagree. There's a lot of tests we need to add. Yes, the underlying delete multiple keys plumbing was actually done from the get go. Just have to go through and expose it in the runtime.
  • j
    nice!
  • v
    Did you manage to replicate it? Just remembered I use wrangler v1 (always need to manually add worker binding on publish), could it be a wrangler v1 issue? I would not expect it to be related, but I am clueless on what is happening
  • v
    I have not. I've been in a meeting for the past hour doing sprint planning. Getting back to this now but the highest order bit for today is to land the perf improvements.
  • j
    noticed that 
    AbortMultipartUpload
    throws 500 when 
    uploadId
    has already been aborted.
  • v
    no problem, thanks and let me know once you can have a look
  • a
    Just bumping this. SHA256 checksumming would allow me to avoid Unbound Workers. And even that might not even work since uploading can take more than 30 seconds.
  • v
    Unbound Workers are not limited to 30s of wall clock time (i.e. how long the upload takes). It's a common mistake to make. Unbound Workers are limited by 30s of CPU time
  • v
    Let's say hashing is 100MB/s, that's ~3 GB you can hash
  • i
    ^ this, while they "have a higher chance of being evicted" after 30s it's likely they won't be.
  • a
    Ooh, gotcha, I been using Workers for a year and always understood it as 30 seconds of duration. This should be clearer haha.
  • v
  • v
    The start about *No limit is about wall clock time
  • v
    I actually personally don't understand the "after 30s there is a higher change of eviction" note. I don't recall seeing anything around wall clock time & eviction in the runtime but it's easy to overlook. I'm getting some clarification internally
  • v
    I'm pretty sure there's definitely a hard 30s CPU limit separate from the wall clock time/eviction note..
  • v
    Ah, ok. So the 30s wall clock is around when we do upgrades of the runtime service
  • v
    We give a 30s grace period
  • v
    So technically that's the guarantee but realistically you'll only see that limitation infrequently.
  • a
    Interesting. Though that feels pretty low. Are there any technical difficulties preventing you from just giving like an hour long grace period?
  • v
    Memory. No way it'll be an hour. But we don't do releases frequently
  • v
    If you're noticing this more than the general noise of errors I would be surprised.
  • i
    Can you clarify a bit? Just interested to know what the issue around memory is.
  • i
    Are you trying to keep 2 V8 runtime versions in memory and that's why you need to terminate the first within 30s to prevent OOM?
  • i
    Oh, neat.
  • v
    That's how transparent cutovers work for all CF infrastructure
  • v
    New requests hit the new code while old requests are given a grace period to terminate
1...596061...1050Latest