GET {db}/_index endpoint response does not reflect index deletion

[vmatyus]

Description

In our pipeline endpoint GET /{db}/_index sometimes does not reflect the ddoc deletion with endpoint DELETE/{db}/_index/_design/{ddoc}/{type}/{index}.

Locally I cannot reproduce the problem, it happens in the pipeline, when multiple database creation/deletion occurs parallelly.

Steps to Reproduce

Here is the full scenario:

1. Create DB with unique name
2. Create index01
3. List indexes with GET {db}/_index(index01 is listed)
4. Delete index01 with DELETE/{db}/_index/_design/{ddoc}/{type}/{index}
5. List indexes with GET {db}/_index (index01 is still listed)

Expected Behaviour

At step 5. the GET {db}/_index request should not include the deleted index field.

Your Environment

• CouchDB version used: 3.0.0-83bdcf6
• Browser name and version:
• Operating system and version: MacOS

Additional Context

According to the discussion on a support channel the bug is that listing the existing indexes only queries an internal cache not the database itself.
It is an open question whether the deleted index ever got removed from the cache, if there is no other database changes.

[rnewson]

mango's "list" function lists the contents of the ddoc_cache which does not accurately represent the list of indexes. In my opinion ddoc_cache should only be used to speed up the loading of design documents on request, it's not appropriate to use it to make any claim about the current state of the database.

One of two paths suggest themselves;

1. change mango list to query the database for the list of ddocs
2. ensure there are bounds of how inaccurate the ddoc cache can get (will an index delete request trigger cache invalidation directly? are we waiting for the LRU to remove this item after a time delay or, worse, only when we hit capacity and must make space for a new ddoc?)