Update:

Apparently it fixed it. It was code that either should have been probabalistically breaking, or breaking all the time. What doesn't make sense to me is that without any code edits it went from never breaking to always breaking.

The code was a result of opting out of using a promise cache pattern where I guess I was lazy for a second. And then also accessing a cache variable directly in other code.

var setCache=null;
async function someUserSet() {
 if(setCache) return setCache;
 const userList = await db.all(...
 setCache = new Set(userList);
 return setCache;
}

That's lazy, but would only ever lead to duplicate reads from the DB if it weren't for other code appending to the cache.

function otherCode() {
 setCache.add(some user);
}

The fix. Proper promise cache pattern. And a duel names for the function. One is what the data is. The other is shorter and what the data is for. This is a positive quirk I've picked up.

async function longDescriptiveFunctionNameRaw() {
 const userList = await db.all(...
 return new Set(userList);
}

var longDescriptiveFunctionNameCache=null;
function longDescriptiveFunctionName() {
 return longDescriptiveFunctionNameCache ||= longDescriptiveFunctionNameRaw();
}

function displaySet() {
 return longDescriptiveFunctionName();
}

function otherFunction() {
 // ... Bunch of code ...
 displaySet().then(i=>i.add(some user)); //Not awaiting
}

The code drives whose name will appear in the connected users list. Basically people who have actually used chat and are connected.