In the meantime I encountered this issue a couple more times. Whenever I start my reviews, they are in meaning-then-reading order although my setting says to prioritize reading. When I leave the reviews and enter them again straight away (from that intermediate screen, not from the dashboard) I always get my reviews in the desired order. So far at least… 
1 Like
I will look into it
1 Like
I have not been successful in reproducing it, so if either of you can try to figure out how to replicate it that would help a lot
Is there a way to access the script’s relevant internal state from the console or so? Or can I add logging somewhere? (E.g. what is the current value of the script’s settings and whatnot.) What information would you need?
1 Like
I have an idea. Extra study uses the same keys in jStorage to track which questions has been answered already as the regular reviews (@TofuguRob is this a potential issue?), and that might be what is causing it, for whatever reason.
We can check this by looking for such keys in jStorage when it happens. You can check this by entering $.jStorage.index() into the console and look for keys such as v6470 (vocab with id 6470). You can check which question(s) has been answered already by retrieving the item $.jStorage.get('v6470'). It will have the keys rc and mc, which stand for reading correct and meaning correct. If rc is set, then the script will not change the question to a reading question. If you want to see which item the number refers to you can query WKOF like this id=6470; (await wkof.ItemData.get_items()).filter(item=>item.id == id)[0].data.characters
1 Like
That’s a good call. I tried Extra Study a few times and I had started to wonder whether that might be related, but I can’t see a clear pattern yet. Will try to find out more tomorrow (once I get new reviews).
1 Like
It happened again, and this time I checked the console:
The explosion happens in Webpack → app/javascript → v03 → review → characters.js in
in line 14 (removeClass()). (but I don’t have enough insight into the code to understand the error message tbh)
This of course caused the Back2Back script to not get loaded at all 
When I left the reviews (back to the in-between-page) and entered again, the script worked normally. When I left again and went back all the way to the dashboard and entered again, it still worked normally.
So I guess there is some caching/flushing race condition (maybe in conjunction with WKOF) being the root cause here?
1 Like
Looks like this error actually occurred in Jitai. Jitai is apparently called because it attached itself to jStorage’s ‘set’ function, so just as Back2Back is setting the question type, Jitai gets called and crashes.
1 Like
Hm, why do you think so? The stacktrace continues way past the call to Jitai though?
Here is the invoked Jitai code in question which looks pretty unsuspicious to me:
On top of that, Jitai has not been updated for almost 3 years, while the WK code where the stacktrace actually ends (i.e. at the top, in the call to updateCharacters()) is probably rather new, I guess…
Would be happy to learn more about this (I don’t know much about browser stuff and promises tbh) so I’d be thankful if you could fill me in as to why Jitai is the culprit!
1 Like
Sorry, I didn’t mean that Jitai was the cause, only that that was the last userscript passed through (rather than Back To Back) before crashing in non-userscript code, so it seemed less likely to be a Back To Back issue, and more likely to be Jitai, based solely on the call stack, especially since the call stack shows that Jitai was intercepting jStorage.set().
[Side note: Regarding “the stacktrace continues way past the call to Jitai”… That’s normal for a stacktrace, which is actually a nested call stack. Errors are typically introduced near the last-called userspace function, where bad parameters are passed to the “system” functions. But, I suppose, since the “system functions” in this case turn out to be WK code, it’s true that there is more likelihood that the error could be because WK code was being triggered (by one of the userscripts) at a time when it wasn’t expecting to be called.]
[Side note 2: Jitai could use jStorage.listenKeyChange() instead of intercepting jStorage.set(). Theoretically, the built-in listener hook would be likely to have some error handling in place to prevent crashed callbacks from affecting other listening scripts… though I glanced at the jStorage code, and they didn’t think to include such error handling, so it turns out not to make a difference.]
3 Likes
I think that what is happening is that I am setting the currentItem to null because activeQueue is still empty when the script runs. I think checking if active queue is empty first (and if it is, waiting until it is not) should do it
FYI, the team is pushing a fix for this.
2 Likes
I just updated the script to wait until the queue is populated, please tell me if that fixes it for you
For me in Extra Study it’s stuck on the first question. I enter the correct answer, it approves, I hit enter… and am asked the same thing again.
It only happens when either reading or meaning is selected in settings. Not when nothing is selected but it’s still active.
Haven’t tried it in any other mode yet because I had no reviews available. Will let you know as soon as there are reviews…
Thanks!
1 Like
It fixes the error in the reviews, thanks! But for Recent Mistakes, I am seeing the same behavior as @miya_maru (i.e. I can’t get past the first question of the first word).
1 Like
That sounds wonderfully hellish. It’s awesome
1 Like
Same here. Reviews work. But Extra Study is stuck on the first question.
2 Likes
@miya_maru @NicoleIsEnough Turns out that your issues were due to WK fixing the above, and not my patch to the script. I have updated the script to reflect WK’s changes
2 Likes
Thanks for the quick fix! It works now 
1 Like
Thank you very much!
1 Like