Multiple tabs don't track items properly. Can lead to incorrect burn

[skatefriday]

@Mods

In general I like no longer having to manage short sessions timeouts, however, the removal of timeouts entirely has resulted in a scenario where if you have a tab open to a review session, move off of that tab, forget that you already had a tab open, start a review session in a second tab, get an item incorrect, wrap up that session, then at some time later move back to the original tab and resume the reviews there, the item that you got wrong in the other tab may appear and if you get it right it will be marked correct.

If this is a burn, then this is really annoying. This should be classified as a legitimate bug with the new review process.

To reproduce:

1. Open a tab, navigate to WK, start reviews.
2. Review half of item A.
3. Go for a walk.
4. Sit back down, leave the WK tab open, but switch to another tab to watch TikTok.
5. Forget that you had a tab open with active reviews.
6. From the TikTok tab navigate to WK and start another review session.
7. Provide the incorrect answer for the second half of item A (check for the correct answer now it’s fresh in your head).
8. Wrap up that session.
9. Do work that pays your bills.
10. Navigate back to the original tab from step 1.
11. Provide the correct answer for the second half of item A.
12. Watch as it shows the item burned.
13. Piss and moan about the lack of a native “Mark Wrong” button in WK.

I think this is a legit bug. I’m pretty sure that’s an accurate description of the process that produced it.

That’s about the third incorrectly burned item I’ve had since the great WK rewrite of 2023 broke the original DoubleCheck script.

Resurrection is not an acceptable solution.

Can the community have some communication as to what WK’s thoughts are with regard to at least a native mark wrong button? I can deal with the bad typing skills. I often type る for つ, when my head is saying the right thing, but the r and t are right next to each other. That just means I review another easy item again, but the whole, we are going to Burn something and not give the user a chance to say, “You know that really shouldn’t have been marked correct.”, well, that just Burns Me Up.

[Cr_nch]

@skatefriday

That’s about the third incorrectly burned item I’ve had since the great WK rewrite of 2023 broke the original DoubleCheck script.

Have you been keeping your scripts up to date? The main double check script people use works fine on the rewrite.

[Userscript]: Double-Check (Version 2.x)

Wanikani Double-Check A multi-feature companion script for Wanikani reviews. (Credit to Ethan for his original version [here]) This is a third-party script/app and is not created by the WaniKani team. By using this, you understand that it can stop working at any time or be discontinued indefinitely. [ General Script Installation instructions ] You’ll need a script host plugin like TamperMonkey [ Open Framework Installation ] [ Download / Install “Double-Check” ] S…

Also, I think this arose from the fact the site no longer uses sessions with arbitrary timeout durations. It means that reviews are only tracked when completed. A similar issue happens if you just refresh the page, resetting all currently active reviews.

@skatefriday

Resurrection is not an acceptable solution.

Genuine question, why not? When you feel confident with the word again, you can just re-burn it.

[skatefriday]

@Cr_nch

Have you been keeping your scripts up to date? The main double check script people use works fine on the rewrite.

I have updated a few, however, I made a decision not to update DoubleCheck because it took longer to update, understandably, and so I had to get by without it for a number of days anyway. I haven’t updated since it’s been migrated to avoid the temptation to mark too many items correct.

@Cr_nch

Also, I think this arose from the fact the site no longer uses sessions with arbitrary timeout durations.

I understand this and noted that I believed the removal of session timeouts was the proximate cause of the bug.

It’s still a bug however. You shouldn’t be able to execute the sequence, correct, wrong, correct, for a given item and have the system think both halves were correct.

@Cr_nch

@skatefriday

Resurrection is not an acceptable solution.

Genuine question, why not?

Because it breaks the SRS pattern. You shouldn’t have to move an item back to Apprentice 1 just because WK has a bug and/or won’t put a “Mark Wrong” feature on their project timeline.

[Cr_nch]

@skatefriday

I haven’t updated since it’s been migrated to avoid the temptation to mark too many items correct.

Understandable, I’m planning on uninstalling the script when I hit level 60 as at that point, typos are irrelevant. (At least for me, because I’m speedrunning this thing)

@skatefriday

You shouldn’t be able to execute the sequence, correct, wrong, correct, for a given item and have the system think both halves were correct.

I would double check a possible work around for this, but I don’t currently have reviews available. Nonetheless, I think reviews are only submitted after advancing to the next review, so refreshing should clear the review.

As for your last point, that’s fair. I personally don’t see a problem with sending something back to Apprentice but to each their own.

[TofuguKyle]

Just a quick note that we’re looking into this. Thank you for bringing it to attention!

[TofuguKyle]

@skatefriday When you have a chance, can you email us at hello@wanikani.com so we can gather some more information?

[skatefriday]

@TofuguKyle

When you have a chance, can you email us at hello@wanikani.com so we can gather some more information?

Did so earlier this afternoon. If you have anything more you need, happy to help.

[tofugu-scott]

@skatefriday I double checked the behaviour but the issue you describe is not reproducible. Let me check that I have the steps right (i am going to ignore waiting time)?

1. Open 2 tabs each pointing to the review page
2. Answer the meaning in tab 1
3. Answer the meaning and reading in Tab 2 but get the reading wrong once.
4. complete the item in tab 2 and see the SRS badge indicating a drop in SRS stage
5. go back to tab 1, complete the item, and see the SRS badge indicating the item is burned

Do these steps adequately correspond to your steps to reproduce the issue or have I misunderstood?

I double checked your reviews and it looks like the incorrect answer was never submitted back to the server first, which is why the item is now burned for you. The way it works is the first item you complete is submitted to the server and the SRS timings are updated. The second time you submit the answer (back in tab 1) it is sent to the server but as the subject is no longer available for review (because it is outside the SRS timings) and we silently drop that submission. The first submission back to the server wins. This has always been how Wanikani works, the only difference is that previously if a tab was left idle for longer than an hour it would force you to refresh.

When you open 2 tabs, or use 2 separate devices, Wanikani does not sync between those independent browser sessions. When the review page loads I send down the current SRS stage for each item and when you complete the item the browser code will determine if you got all answers correct for that item and show the appropriate SRS badge. This is why would still see burned on tab 1 even after you saw a downgrade to guru on tab 2.

[Kazzeon]

I figured it was something like this, I think someone else mentioned something similar before, and it’s just an issue in what the user sees, not what the site does. Unless they could show proof that it impacted their data, though you probably checked.

[skatefriday]

It happened again. A little different workflow this time.

In tab one I answered the meaning for 大敵 correctly, switched to tab 2, answered the reading incorrectly (shakes fist at だい vs たい), switched back to tab 1 answered the reading correctly and it burned the item.

Switched back to tab 2, eventually 大敵 came back up for it’s reading again, because of course I had answered it wrong the first time.

Here’s tab one showing last ten items…

Here’s tab two showing also with the last ten items. Somewhat interestingly it is showing 大敵 as burned as it is asking me for the meaning, after having gotten the meaning incorrect in the second tab.

I intentionally entered the wrong meaning in tab two a second time to see what it would do, and it does appear to have thrown that answer away.

However in tab 2 it came back around again and when I entered the correct reading, it showed it as Guru

Interestingly enough I now see how you determine correct answers on the backend…

This time, paying pretty close attention to it, the order was, correct meaning (tab 1), wrong reading (tab 2), correct reading (tab 1), burned, discarded meaning (tab 2).

Unlike yesterday, I did not wrap up the session in tab 2 before moving back to tab 1. I’m pretty sure yesterday I wrapped up the session which would have resulted in the incorrect submission winning, but that’s not what appears to have happened, but I will admit to not perhaps paying close enough attention because I wasn’t actually looking for it.

At any rate, what I did today resulted in an incorrect burn, and it corresponds with what you described would happen. Which argues pretty strongly for a native Mark Wrong button.

[skatefriday]

Here’s the opposite where I got an item incorrect in tab 2, wrapped up tab 2 and in tab 1 answered both sides correctly. (shakes fist at transitivity)

You can see here that tab 2 won. And it does appear that you will throw this result away on the server?

I understand that it can be hard to detect this in real time, but I think the origin of the bug is that it is possible for the WK server to send the same item to two different tabs. Once an item has been fetched for review, it should not be possible to fetch it for review again until a result has been obtained. And, yeah, I understand that this implies a session cause what if a user closes a tab with reviews ongoing without submitting a result for some set of reviews. Then they are in a no-fetch state. Could be tricky to solve that problem.

[tofugu-scott]

@skatefriday

Unlike yesterday, I did not wrap up the session in tab 2 before moving back to tab 1. I’m pretty sure yesterday I wrapped up the session which would have resulted in the incorrect submission winning, but that’s not what appears to have happened, but I will admit to not perhaps paying close enough attention because I wasn’t actually looking for it.

I did check your review data and the server got your correct answer sumbission first before it got the incorrect submission.

@skatefriday

Interestingly enough I now see how you determine correct answers on the backend…

Just to make sure it is clear (and I am sure it is), I only send the result to the server when you have answered both parts of the item (or just the meaning for a radical).

@skatefriday

This time, paying pretty close attention to it, the order was, correct meaning (tab 1), wrong reading (tab 2), correct reading (tab 1), burned, discarded meaning (tab 2).

@skatefriday

At any rate, what I did today resulted in an incorrect burn, and it corresponds with what you described would happen. Which argues pretty strongly for a native Mark Wrong button.

@skatefriday

You can see here that tab 2 won. And it does appear that you will throw this result away on the server?

This lines up with the way I described it. The browser doesn’t know you have a part done item in another tab (or another device for that matter). So from a technical standpoint the system is working as intended. However if I understand you correctly you have a couple of feature requests:

1. You would like to have the ability to retrospectively mark an item as wrong, effectively turning your burned item into a guru’d item rather than resurrecting it all the way back to 0
2. You want the notion of a session where items belong to only one session and once an item belongs to a session it can’t be part of another session to protect yourself from forgetting you have another tab open with an ongoing review.

Item 1 above is something we have been considering and is in our potential feature backlog. We have recently discussed this in regard to the replacement summary page that we are stil actively working on. The idea is still being evaluated which is all I can say at this point.

Item 2 however is really complex, requires lots of handshaking between client and server, probably requires some polling to indicate that session is still active, which may not occur if the browser puts background tabs to sleep; would require some way to recover the session should you accidentally close the tab; in short, it is way to complex to get right and will cause more issues than the problem it is trying to solve.

[Gorbit99]

@tofugu-scott

Item 2 however is really complex, requires lots of handshaking between client and server, probably requires some polling to indicate that session is still active, which may not occur if the browser puts background tabs to sleep; would require some way to recover the session should you accidentally close the tab; in short, it is way to complex to get right and will cause more issues than the problem it is trying to solve.

Couldn’t you do the opposite? As in mark on the server when the user last did reviews, and if someone goes back to a previous session, and the site sees, that the locally stored latest timestamp is off from the one the server responds with, just reload the page or warn them or whatever. That way if they open a new page and do reviews, then go back, once they try to submit a review, the page will know about the discrepency.

[kirun]

I think I’ve triggered something similar by accidentally refreshing the page on mobile, it loses the half reviews and I can get a SRS advance on an item that should have fallen back. This would seem equivalent to using two tabs.

[skatefriday]

@tofugu-scott

• You would like to have the ability to retrospectively mark an item as wrong, effectively turning your burned item into a guru’d item rather than resurrecting it all the way back to 0

A very strong, “Yes please.”

@tofugu-scott

• You want the notion of a session where items belong to only one session and once an item belongs to a session it can’t be part of another session to protect yourself from forgetting you have another tab open with an ongoing review.

If I had the ability to “Mark Wrong” natively within WK, I’d have no strong desire to need this notion of a session.

I completely understand that sessions, wherein you don’t just revert everything you did to get rid of sessions, and yet still retain the ability to know on the backend what the user is currently reviewing is a heavy lift.

I’d prefer the the Mark Wrong feature be inline with the reviews rather than ex-post-facto in a review summary page. Ideally there would be a new API endpoint that applies an incorrect answer operation to any item. Then I could partially resurrect any item I wanted to independent of reviews which I think I’d find valuable. Alternatively you defer sending the result of a completed review back to WK until the operation that loads the next item (similar to what DoubleCheck does) which would allow you to increment your incorrect counter prior to sending the results json.