This is an automated email from the ASF dual-hosted git repository. vatamane pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/couchdb.git
commit 16c147781b3bf9e1bc086bf1c89b070d7bd22100 Author: Nick Vatamaniuc <[email protected]> AuthorDate: Thu May 29 15:25:02 2025 -0400 Handle shard opener tables not being initializes better Previously, we handled the case of missing ets tables by catching `error:badarg` in places like `for_db/2`, but then forgot to handle it the lower level `maybe_spawn_shard_writer/3` function, so call was still crashing and making a mess in the logs. This is more apparent on startup with nodes being upgraded in a busy cluster. --- src/mem3/src/mem3_shards.erl | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/mem3/src/mem3_shards.erl b/src/mem3/src/mem3_shards.erl index d37539db4..d256d3e90 100644 --- a/src/mem3/src/mem3_shards.erl +++ b/src/mem3/src/mem3_shards.erl @@ -526,11 +526,17 @@ cache_clear(St) -> St#st{cur_size = 0}. maybe_spawn_shard_writer(DbName, Shards, IdleTimeout) -> - case ets:member(?OPENERS, DbName) of + try ets:member(?OPENERS, DbName) of true -> ignore; false -> spawn_shard_writer(DbName, Shards, IdleTimeout) + catch + error:badarg -> + % We might have been called before mem3 finished initializing + % from the error:badarg clause in for_db/2, for instance, so + % we shouldn't expect ?OPENERS to exist yet + ignore end. spawn_shard_writer(DbName, Shards, IdleTimeout) ->
