Notices not being send under some circumstances

javascript

#1

PhantomBot Version: 2.4.0.3-NB-20180509 (Revision: 3887b3e)
Control Panel Version 1.1
Java Version: 1.8.0_171-b11
OS Version: Windows 10

Control Panel Software
jQuery 1.10.2
jQuery UI 1.11.4
Bootstrap 3.3.6
Font Awesome 4.5.0
Ion.Sound 3.0.7
FlotCharts 0.8.3
FooTable 3.0.10

I noticed the other day that the Notices were not being triggered when I deleted some of them.
The bug happens when you have several notices and the bot has been running for some time and you remove all but one notice.
Let’s say you have 4 notices, the bot will start at index 0 incrementing the counter on every successful post to chat. So if you are on index 2 and remove all but one the bot will keep forever and ever try to send the notice at index 3 which no longer exist.
The following is a copy of the log:
[05-10-2018 @ 17:15:02.824 GMT] [CHAT] /me test 0
[05-10-2018 @ 17:20:02.838 GMT] [CHAT] /me test 1
[05-10-2018 @ 17:25:02.852 GMT] [CHAT] /me test 2
[05-10-2018 @ 17:30:02.866 GMT] [CHAT] /me test 3
[05-10-2018 @ 17:35:02.878 GMT] [CHAT] /me test 0
[05-10-2018 @ 17:40:02.894 GMT] [CHAT] /me test 1
[05-10-2018 @ 17:49:39.576 GMT] edsmcr: something

At 17:41 I deleted notices 1 to 3 leaving only 0. But since the next index to be sent was supposed to be 3 it will always fail to send it.

The

RandomNotice

variable needs to be reset if the sendNotice() function fails.


#2

I think I see what is going on and I think the easy fix is to reset RandomNotice in reloadNotices(). The logic to reset it never gets reached in sendNotice() in the condition you mention, I believe.

    function sendNotice() {
        var EventBus = Packages.tv.phantombot.event.EventBus,
            CommandEvent = Packages.tv.phantombot.event.command.CommandEvent,
            notice = $.inidb.get('notices', 'message_' + RandomNotice);

        if (notice == null) {  <-- this is true, it hits null so returns.
            return;
        }

        RandomNotice++;

        if (RandomNotice >= numberOfNotices) {  <-- then this is never reached
            RandomNotice = 0;
        }

#3

Fixed in 1991.

Note that this fix just resets the counter back to 0 (the beginning). While not perfect, it will at least ensure that notices keep firing in this condition. As notices are renumbered after a massive delete operation, it is difficult to know what the last one was after the reordering.


#4

Also, thank you for the very thorough and descriptive bug report. This made it easy to understand what was going on. Very much appreciated!


#5

No problem. I’m glad to help.
Thanks for the fix.