Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭 适合新手
  • 哪里不对？
#6,142 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
1/5
预计耗时
1 小时以内
新手友好度
90/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
erlang
领域
api, backend, databases

调研方向

从 src/fabric/src/fabric_db_delete.erl 中的 fabric_db_delete:maybe_stop/2 开始，具体检查每个 shard 都返回 not_found 的分支。检查警告格式，并使用报告中的 concurrent-reader 复现来验证完成后的行为：第二个 DELETE 返回带有 not_found 的 404，并记录警告，而不是产生 500 badarg。

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Erlang
星标
7k
派生
1.1k
平均合并
15 小时 18 分钟
30 天内合并 PR
35

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

apache/couchdb 的其他 Issue

查看 apache/couchdb 的全部 Issue

相似的 Issue

更多 Backend & API Design Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。