We hit a failing test and traced it back to the way repositoriesdb behaves when it is called multiple times in the same process with different loading contexts.
Right now, repositoriesdb keeps global in-memory state and its behavior depends on call order. That becomes fragile when we mix filtered and unfiltered repository loads, unrelated earlier calls that populate the cache before a later operation needs a different view.
In practice, this means a previous repositoriesdb call can affect a later one in a way that is not obvious from the caller. We already had to add defensive clear_repositories_db() calls in some updater paths to avoid stale state causing incorrect behavior.
We hit a failing test and traced it back to the way repositoriesdb behaves when it is called multiple times in the same process with different loading contexts.
Right now, repositoriesdb keeps global in-memory state and its behavior depends on call order. That becomes fragile when we mix filtered and unfiltered repository loads, unrelated earlier calls that populate the cache before a later operation needs a different view.
In practice, this means a previous repositoriesdb call can affect a later one in a way that is not obvious from the caller. We already had to add defensive clear_repositories_db() calls in some updater paths to avoid stale state causing incorrect behavior.