Perafan18 opened a new issue, #6142:
URL: https://github.com/apache/couchdb/issues/6142
### 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:
```erlang
%% 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.
```sh
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](https://github.com/rubylab-app/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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
