Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Bug]: DELETE /{db} returns 500 badarg instead of 404 when the shard map cache still lists a just-deleted database

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#6,142 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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ó
1/5
Thời gian dự kiến
Dưới một giờ
Mức phù hợp với người mới
90/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ệ
erlang
Lĩnh vực
api, backend, databases

Hướng nghiên cứu

Bắt đầu trong src/fabric/src/fabric_db_delete.erl tại fabric_db_delete:maybe_stop/2, cụ thể là nhánh trong đó mọi shard trả về not_found. Kiểm tra định dạng cảnh báo và xác minh hành vi sau khi hoàn tất bằng reproduction concurrent-reader đã được báo cáo: DELETE thứ hai trả về 404 với not_found và cảnh báo được ghi log thay vì tạo ra 500 badarg.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Version

3.5.1

Describe the problem you're encountering

Right after a database is deleted, a second DELETE /{db} can answer 500 {"error":"unknown_error","reason":"badarg"} instead of 404 not_found. The stack trace in the log points to fabric_db_delete:maybe_stop/2.

That branch should turn "every shard answered not_found" into {stop, not_found}, but it crashes while formatting its own log message:

%% src/fabric/src/fabric_db_delete.erl (line 79 in 3.5.1, line 78 in 3.5.2 and main)
{W, 0, W} ->
    {#shard{dbname = Name}, _} = hd(Counters),
    couch_log:warning("~p not_found ~d", [?MODULE, Name]),
    {stop, not_found};

Name is a binary, so ~d raises badarg and the request fails with a 500.

This branch is only reached when the shard map cache (mem3) still lists the database after it was deleted, for example when a read that raced with the deletion put its shards back in the cache. Until the cache catches up, other requests on that database also fail with 500 "No DB shards could be opened.". That part may be expected while the deletion propagates; the badarg is not.

Expected Behaviour

The second DELETE should answer 404 {"error":"not_found","reason":"Database does not exist."}, and the warning should be logged. Using ~s (or ~p) instead of ~d in that format string should be enough.

Steps to Reproduce

On a single-node CouchDB 3.5.1 (couchdb:3.5.1 Docker image, default config). Replace $COUCH with the server URL including admin credentials.

DB=badarg_repro
curl -s -X PUT "$COUCH/$DB"
# a few concurrent readers
for i in 1 2 3 4; do
  ( while true; do curl -s -o /dev/null "$COUCH/$DB"; done ) &
done
curl -s -X DELETE "$COUCH/$DB"   # {"ok":true}
curl -s -X DELETE "$COUCH/$DB"   # often: 500 {"error":"unknown_error","reason":"badarg","ref":...}
kill %1 %2 %3 %4

With this script, the second DELETE answered 500 badarg (always "ref":17476293) in 14 of 40 runs on our machine; a tighter loop hit it in 188 of 200. With no concurrent readers it did not reproduce (0 out of 150).

Your Environment
  • CouchDB 3.5.1, official Docker image, single node
  • Seen from the CouchDB integration tests of rouchdb, on a GitHub Actions Linux runner and on Docker Desktop for macOS
Additional Context

The format string is the same in 3.5.2 and on main, so those are likely affected as well. On the client side we now retry these 500s for about a second after a delete.

Ngôn ngữ chính
Erlang
Star
7k
Fork
1.1k
Merge trung bình
2 ngày 10 giờ
Pull request đã merge (30 ngày)
18

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/couchdb

Tất cả issue của apache/couchdb

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.