It should not be that, although libramBurn is a before battle script, I believe.
Consider concurrent requests in KoLmafia:
The GUI - "automation" - submits requests and waits for responses. While it is idle, it is green; UI controls are active, and you can tell it to execute actions. While it is busy, it is red, and UI controls are supposed to be disabled. When it is ready to accept user input again, it enables UI controls and goes green or red, depending on whether the last action succeeded or failed. In either case, it is ready for more work.
The gCLI is part of the GUI and can be used to run commands or scripts - more "automation" - but is not disabled while this is happening. That is why you can type more commands and they get QUEUED. But, while a CLI command or script is running, the rest of the GUI is supposed to be disabled, preventing multiple threads of "automation" from happening at once.
The Relay Browser is its own thing. Browsers can make multiple requests to KoL without waiting for earlier ones to complete. We see this most commonly for downloading multiple images at once, but you can start a new adventure while the Browser is waiting for a previous charpane refresh to happen, for example. Not to mention chat, which can happen while anything else is happening.
Now, while you are adventuring in the Relay Browser, we do not lock out the GUI. There is nothing to stop you from attempting automation, either by clicking on UI buttons in the GUI or by executing CLI commands. I vaguely remember another Feature Request (or perhaps just a discussion) suggesting that the GUI & CLI be locked while you are adventuring, but I think that is extremely unlikely to happen.
What I did do was to lock out some kinds of requests - use item, equip, familiar change - to fail without submitting a request if we know that you are in a fight or choice adventure. Perhaps we don't do that for use skill requests. We probably should.
There is another open bug report in which somebody caused themself a lot of trouble by executing an outfit change - apparently via a maximizer command - and then impatiently going to the Relay Browser and ending up in a non-abortable choice adventure.
What we have here, however, is a between-battle-script - libramBurn - and Relay Browser adventuring. Yes, you can set preferences to recover HP, maintain MP (including mana burning), maintain moods, and run betweenBattleScript before manual adventuring. We do that in the thread that handles a Relay request by recognizing that the request constitutes an "adventure" and proceeding to do all those other actions before we submit the adventuring request to KoL. In other words, it really should not be a case of simultaneous requests; a "long running between battle script" will just run for a long time and THEN we will submit the request.
Now, if you get impatient in your Browser and click "Adventure Again" a second time while the previous request executes the between battle actions, we will notice that recovery is still happening and will skip that and just submit the request. And in that case, we will have simultaneous requests going on, and when the first thread finishes and submits the request, you will certainly see a "twiddle your thumbs" sort of thing.
In summary, I see two possibilities here:
- The user is executing something in the gCLI while also adventuring in the Relay Browser
- The user really did click Adventure Again (or the equivalent button on the CAB) twice and submitted two requests.
My response to that is probably "don't do that", in which case, this becomes a Won't Fix. However, until and unless we get a DEBUG log - preferably one with the "Verbosely log communication between KoLmafia and browser" checked in General/Extra Debugging - there is nothing we can say about what really happened.
