cloudflare / cloudflare/developer-platform

BUG: `wrangler r2 object get --remote` returns stale data for `.zst` keys after overwrite/delete

Đang mở

#53 mở ngày 20/3/2026 0 bình luận 0 reaction 1 người được giao Được @aninibread nhận Xem trên GitHub

product:r2

Ngôn ngữ chính: Không có dữ liệu ngôn ngữ
Star: 1
Fork: 0
Chỉ số merge pull request: Không có pull request nào được merge trong 30 ngày

Mô tả

### What versions & operating system are you using?

```
$ npx envinfo --system --npmPackages '{wrangler,create-cloudflare,miniflare,@cloudflare/*}' --binaries
System:
OS: Linux 6.8 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
CPU: (32) x64 AMD RYZEN AI MAX+ 395 w/ Radeon 8060S
Memory: 26.00 GB / 30.99 GB
Container: Yes
Shell: 5.2.21 - /bin/bash
Binaries:
Node: 22.21.1 - /home/whitegreen/.local/share/mise/installs/node/22.21.1/bin/node
npm: 10.9.4 - /home/whitegreen/.local/share/mise/installs/node/22.21.1/bin/npm
```

### Please provide a link to a minimal reproduction

https://gist.github.com/White-Green/fda499806e74382b7bb6538d81659c45

### Describe the Bug

`wrangler r2 object get --remote` appears to return stale data for object keys ending with `.zst`.

For keys without that extension, such as `file1` and `file2.txt`, overwrites and deletes are reflected correctly.

For a `.zst` key such as `file3.zst`:

- after overwriting the object with `wrangler r2 object put --remote`, `wrangler r2 object get --remote` still returns the old content
- after deleting the object with `wrangler r2 object delete --remote`, `wrangler r2 object get --remote` still returns the old content
- the same key accessed through the S3-compatible API (`aws s3 cp`) shows the correct latest state, and returns 404 after deletion

In my reproduction, `wrangler r2 object get --remote` continues to return stale data for `file3.zst` even after the bucket itself has been deleted.

Expected behavior:
- `wrangler r2 object get --remote` should return the latest contents after overwrite
- it should return `The specified key does not exist.` after delete
- behavior should not depend on the file extension

reproduction log (equals of gist)

```sh
whitegreen@tobari:/tmp/r2-repro$ ls -la
total 248
drwxrwxr-x 2 whitegreen whitegreen 4096 Mar 20 07:10 .
drwxrwxrwt 57 root root 245760 Mar 20 07:00 ..
whitegreen@tobari:/tmp/r2-repro$ npx wrangler@4.75.0 r2 bucket create 20260320-whitegreen-issue

⛅️ wrangler 4.75.0
───────────────────
Creating bucket '20260320-whitegreen-issue'...
✅ Created bucket '20260320-whitegreen-issue' with default storage class of Standard.
To access your new R2 Bucket in your Worker, add the following snippet to your configuration file:
{
"r2_buckets": [
{
"bucket_name": "20260320-whitegreen-issue",
"binding": "_20260320_whitegreen_issue"
}
]
}
whitegreen@tobari:/tmp/r2-repro$ echo "file content 1" > file
whitegreen@tobari:/tmp/r2-repro$ npx wrangler@4.75.0 r2 object put --remote 20260320-whitegreen-issue/file1 --file ./file