Bug breakfast not updating _genieWishesUsed the 3rd time when making pocket wishes

fredg1

Member
This is only the second time this ever happens, but it's still... peculiar.

Code:
use 1 genie bottle
Took choice 1267/1: (secret choice)
choice.php?whichchoice=1267&wish=for+more+wishes&option=1
You acquire an item: pocket wish
Preference _genieWishesUsed changed from 0 to 1

use 1 genie bottle
Took choice 1267/1: (secret choice)
choice.php?whichchoice=1267&wish=for+more+wishes&option=1
You acquire an item: pocket wish
Preference _genieWishesUsed changed from 1 to 2

use 1 genie bottle
Took choice 1267/1: (secret choice)
choice.php?whichchoice=1267&wish=for+more+wishes&option=1
You acquire an item: pocket wish
Preference breakfastCompleted changed from false to true
Preference lastBreakfast changed from -1 to 2

I don't know why, but the preference _genieWishesUsed wasn't updated after having made the 3rd pocket wish.

Because of how the "search in folder" tool works, I can't really find the exact other time it happened, but I remember looking at the GCLI, that day, and seeing that it was, that time, too, the 3rd pocket wish creation that didn't update _genieWishesUsed.

Frankly don't have high hopes in regards to fixing this bug, since visibly hard to replicate to begin with, and I don't see how there could be a "reason" for it to happen (so no "EUREKA! THIS line is what triggered the bug!"), but posting this just in case.
 

Veracity

Developer
Staff member
Is that, literally, everything that was in the session log?
You were using genie wishes as part of breakfast?
Was the Relay Browser open with Guide running?

It is unfortunate that we have global static variables in various places. ChoiceManager has variables that determine if we are still in a choice when we going through GenericRequest's handling of a particylar response. That means that if it is interrupted and another request's response comes in and is processed, it can muck with those variables. ChoiceManager has code to ignore certain requests which can come in asynchronously which don't indicate that we are walking away from the choice - desc_item.php, chat, api, charpane, etc.

The method that increments the _genieWishesUsed property is in postchoice2 - which is only called if we are currently processing a choice.
If we start processing the choice response and another request asynchronously comes in and clears the "handling choice" variable, that response might not get called.

Guide runs asynchronously and makes who-knows-what requests that can interrupt processing other requests anywhere.

Without a DEBUG log showing the responses coming in for various requests and showing this kind of asynchronous interruption, there is nothing I can do about this.
 

fredg1

Member
(sorry for the delay, my hard drive malfunctioned)

This is the very end of a day's breakfast - nothing was trimmed in-between; what follows is irrelevant; what precedes was just me waiting for breakfast to complete (pocket wish creation is done at the very end of (my?) breakfast).
If I recall correctly, this was after an ascension, so relay browser was open, along with guide.
 
Top