Ok, so this is another horrible non-deterministic one without a clear reproduction path. Sorry. I've spent a few hours trying to nail this down better but without being able to look at the code/put in debug logging I'm not getting anywhere. It does happen occasionally with the following small code snippet: on('chat:message', (msg) => {
if(msg.content === '!test') {
const playerName = getObj('player', msg.playerid).get('displayname');
const start = Date.now();
let now = Date.now();
log(start);
sendChat('', `/w "${playerName}" Starting`, null, {noarchive:true});
while (now < start + 500) {
now = Date.now();
findObjs({type:'attribute'});
}
log(now);
sendChat('', `/w "${playerName}" Ending`, null, {noarchive:true});
}
}); Reproduction steps are a little tricksy: Ensure that you have sound turned on and volume up Start a new game and enter it as GM Turn on background chat beeps if not already enabled Invite and add a separate Roll20 account as a player in the game Open a separate browser/private browsing window and join as the player Run !test as the player with the GM browser window still open in the background Expected result: You get two chat messages whispered to the player, with no chat notification beep on the GM's browser since the GM doesn't receive the whisper Actual result: You get two chat messages whispered to the player, and then, a few seconds later (be patient, don't switch away from the player browser), you get a chat beep from the GM browser. When you switch to the GM's browser, however, there's no message in the chat window. This doesn't happen reliably, but once it *does* start happening you can keep doing it by rerunning !test and it seems to keep happening reliably from then on. It's like there's a broken state that it's not straightforward to get into, but once you're there, it persists until you reset things somehow (refresh perhaps?). I've seen this happen with only one chat message being sent, so I don't think the pairing is essential. In general it *seems* to happen more when the API command takes longer to execute (thus the delay in the example script), but I've tried playing with different delay values and there's no reliable relationship. Up until now I've only been able to reproduce this with the player initiating the command and the GM in the background, but I can't be 100% sure that this is essential to the issue. My test campaign is relatively small: 5 maps and a dozen journal entries, so I don't think it's that. My net connection is ok but not great - pings of 50-80ms to app.roll20.net with very occasional packet loss when the WiMAX signal bounces off a bird before it reaches the antenna on the top of the mountain opposite :-) This might seem like a deeply obscure and not very significant issue when presented like this, but the real context is much more frustrating: if you have 4 players regularly running API commands that whisper output back to them, the GM gets constantly bombarded with chat beeps, only to find no messages in the chat window when she looks there - which essentially makes the chat beep useless as a notification. I'm sorry I can't provide a more reliable reproduction path, but I can assure that it *does* definitely happen - so perhaps at some point a dev could (a) have a look at the code that handles the chat notification to see if there's an obvious race condition in there and/or (b) throw some extra logging in so that you can grab some more useful data when it does recur....
