`cf workers secrets update` replaces the entire secret set instead of patching a single secret
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 68/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
Hướng nghiên cứu
Start at the cf workers secrets update command entry point and compare its dry-run request with cf workers secrets bulk, including the /secrets and /secrets-bulk endpoints. Reproduce the two-secret sequence from the issue and inspect the existing command tests or request handling. Done means updating one secret leaves other secrets unchanged, with coverage for the reported sequence or clearly documented replacement behavior.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
cf version: 1.0.0-beta.5, macOS
What happens
cf workers secrets update <NAME> --worker <worker> --type secret_text --text <value> sets the named secret, but silently deletes every other secret already on the Worker — it's not a patch, it's a full replace.
Hit this for real while migrating a production Worker (8 secrets already set via wrangler secret put, working fine). Ran cf workers secrets update RUN_TOKEN --worker web-qa-jev-agent --type secret_text --text "<new-token>" to rotate one token. cf workers secrets list --worker web-qa-jev-agent immediately after came back [{"name": "RUN_TOKEN", ...}] — the other 7 (GitHub App auth, webhook secret, target URL) were gone. Broke GitHub App auth and a webhook trigger until manually restored via wrangler secret put.
Repro
cf init repro-cf --package-manager npm
cd repro-cf
cf deploy # after declaring at least one bindings.secret() per #70/#72's workaround, or use --secrets-file
cf workers secrets update FIRST --worker repro-cf --type secret_text --text a
cf workers secrets list --worker repro-cf # [FIRST]
cf workers secrets update SECOND --worker repro-cf --type secret_text --text b
cf workers secrets list --worker repro-cf # [SECOND] -- FIRST is gone
What I found
cf workers secrets update --dry-run shows exactly why:
{
"command": "cf workers secrets update",
"method": "PUT",
"url": "https://api.cloudflare.com/client/v4/accounts/{account}/workers/scripts/{script}/secrets",
"body": { "name": "SECOND", "type": "secret_text", "text": "b" }
}
It's a PUT to the plain /secrets collection endpoint with only the one secret in the body — a full replace, not a merge. Compare to cf workers secrets bulk --dry-run with the same secret:
{
"command": "cf workers secrets bulk",
"method": "PATCH",
"url": "https://api.cloudflare.com/client/v4/accounts/{account}/workers/scripts/{script}/secrets-bulk",
"body": { "SECOND": { "type": "secret_text", "text": "b" } }
}
bulk hits a different endpoint (/secrets-bulk) with PATCH/RFC 7396 merge semantics — its own --help text even says "Secrets not included in the request are left unchanged" and recommends it over update for multi-secret changes. But nothing in update's own --help or command name suggests that a single-secret call is just as destructive to every other existing secret. This looks like the same root-cause family as #70/#72/#54 (PUT-only API, no merge-on-single-field-update), specifically for the one command whose entire job description ("Add a secret to a Worker script") implies it should be additive.
Expected
cf workers secrets update either performs a genuine patch (e.g. by using the bulk/secrets-bulk endpoint under the hood when only one secret is given), or its --help/docs state unambiguously that it replaces the whole secret set — right now the command name and description ("Add a secret...") actively suggest the opposite of what it does.
Workaround
Use cf workers secrets bulk --body '{"NAME": {"type": "secret_text", "text": "value"}}' instead of update, always, even for a single secret on a Worker that has others set.
- Ngôn ngữ chính
- TypeScript
- Star
- 916
- Fork
- 53
- Merge trung bình
- 18 giờ 37 phút
- Pull request đã merge (30 ngày)
- 197
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của cloudflare/cf
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
cloudflare/cf#344 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
upstream
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
cloudflare/cf#262 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`cf dev` rejects `--port` and `--host` for Vite projects, including the `cf init` templateCó thể đã có người làm @jamesopstad đã nhận 12 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
cloudflare/cf#223 · 2 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
upstream
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
cloudflare/cf#179 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 58/100
cloudflare/cf#406 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của cloudflare/cf
Issue tương tự
-
VS Code extension: clickable file links in chat drop the :line suffix, never jump to the lineĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
MoonshotAI/kimi-code#4398 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Xiaomi Mimo语音识别服务异常Đang mởpending triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
package-lock.json : les binaires natifs macOS et Linux de unrs-resolver ont disparu depuis #1823Đang mởbug dependencies
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
AxaFrance/design-system#2064 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100