/_{db}/_ensure_full_commit returns success for non-existent databases

[flimzy]

If I attempt to call the _ensure_full_commit endpoint for a database with a name beginning with the '_' character, I get (fake) success, rather than 404.

Expected Behavior

I expect a 404, as I get for a db with a standard name. Example:

curl -X POST http://admin:abc123@localhost:6004/foo/_ensure_full_commit -H 'Content-Type: application/json'
{"error":"not_found","reason":"Database does not exist."}

Current Behavior

Apparent success, even though the database _foo does not exist.

curl -X POST http://admin:abc123@localhost:6004/_foo/_ensure_full_commit -H 'Content-Type: application/json'
{"ok":true,"instance_start_time":"0"}

Context

Observed on CouchDB 2.2.0, but not on 2.1.1 and older. Tested using Docker images.

[wohali]

Any attempts to access /_* endpoints are not real databases, but system endpoints.

Port 6004 is unusual, can you confirm this is the standard clustered (port 5984) port and not the node-local (port 5986) port?

[flimzy]

Yes, sorry, 6004 is mapped to 5984 on my docker container (the unusual port mapping is to accommodate multiple versions of CouchDB running).

[eiri]

@flimzy thank you for reporting. This is a result of refactoring where previously the calls to a non-existent database were intercepted up the chain by auxiliary security check. I've opened PR #1588 to address this issue.

By the way, I don't know if you aware, but in 2.x a call to /db/_ensure_full_commit is a noop operation that's always returning 201. I don't know for sure, but I suspect it was done just to keep API's back compatibility.

[flimzy]

By the way, I don't know if you aware, but in 2.x a call to /db/_ensure_full_commit is a noop operation

I wasn't aware. It looks like this needs to be updated in the documentation. I'll try to find time to do that soon, if nobody beats me to it.