API ISSUE: Incorrect Kanji Reading in 3rd Party Apps

[Joeni]

I’m getting a dozen or so emails a day about this as the maintainer of Smouldering Durtles and so I thought it might be sensible to make a post in the hopes that people see this rather than worry about their recall or assume an app specific issue.

As of a few days ago (presumably as Tofugu set everything up for a winter break) the API endpoint (the thing 3rd party apps talk to for info) started providing subject information that in some cases had the true/false flipped for the kun/on readings of kanji.

The result of this is lots of people getting shakes saying they’re entering the wrong reading when doing reviews on 3rd party apps.

Smouldering Durtles (thanks to the community of contributors) has been updated with a workaround for this, but any un-updated app is likely to have this issue until Tofugu fix the API.

Please try not to bug app maintainers directly about this too much, as there’s not very much we can do about it unfortunately.

[Belthazar]

Have the mods actually been tagged or otherwise contacted about this yet?

[tofugu-scott]

@Joeni Thanks for bringing this to my attention. I saw your ping the other day but assumed it related to something I had already fixed.

[Android] Smouldering Durtles (v1.1.5) - native app with offline lessons and reviews, plus themes and script-like features!

I’ve not done any manual checks of the API responses, but it certainly appears to me that it may have been temporary. As I mention, forcing a database reset causes it to correctly display the expected readings. It may be that it was at some point recently giving the incorrect relationships and has now been resolved. I think only @tofugu-scott could say for sure.

I rechecked the fix I made last week and have just deployed another update to the API that should resolve the issue.

Background

I recently made an update to our Admin system that prevented subjects from having more than one primary reading or meaning. As a consequence the accepted answer field that is used in the API started reporting incorrectly for kanji as previously all accepted answers were primary readings. The fix I deployed last week resolved this issue when you fetch an individual kanji, however when you fetched a collection of subjects I incorrectly cached a variable that meant all subsequent kanji would use the same value for the accepted answer of the first kanji in the collection.

I didn’t realise this was still an issue until you posted here and on reddit. In future it would be super helpful if you reported the bug to hello@wanikani.com as that would then get logged into our issue tracker and we would get to a resolution much faster.

Once again thanks for posting this here and my apologies for the issues with the API.

[Joeni]

Hi Scott, thank you for looking at this during the holiday period - I understand getting a lot of pings about stuff (especially when you think it’s fixed already) can be very vexing.

Thank you for explaining the context, we had suspected it may be related to caching, so that makes sense. I’m glad it was possible for you to make a fix to it

@tofugu-scott

I didn’t realise this was still an issue until you posted here and on reddit. In future it would be super helpful if you reported the bug to hello@wanikani.com as that would then get logged into our issue tracker and we would get to a resolution much faster.

Noted! I only did not do so myself because a number of people had reported doing so already and I didn’t want to inundate you any further

[tofugu-scott]

@Joeni

Noted! I only did not do so myself because a number of people had reported doing so already and I didn’t want to inundate you any further

I just checked and the only report I could find related to the initial bug report 7 days ago and then the user reported that the fix I deployed worked for them. It appears no one else reported the issue (or maybe my search is a little off). Anyhow, it is always safest to assume that others haven’t reported the bug and report it anyway.

Should all be fixed now. If you are still having trouble please do raise a bug report via an email and I will look into it as soon as it is bought to my attention.

Thanks and have a wonderful and safe Christmas period.

[Joeni]

@tofugu-scott

I just checked and the only report I could find related to the initial bug report 7 days ago and then the user reported that the fix I deployed worked for them. It appears no one else reported the issue (or maybe my search is a little off). Anyhow, it is always safest to assume that others haven’t reported the bug and report it anyway.

Ah, perhaps it wasn’t clear it was related, @gunt3001 was pretty explicit that they’d submitted this issue already and having suffered through six years of support work previously, I know that multiple reports on incidents can just distract from the action

@gunt3001

Specifically, if the app tries to download ALL subjects whole-sale WK API will return this erroneous result. This does not happen if a specific subject/kanji is requested - the response is correct in that case. This also explains why some apps might not have issues while others do. It depends on how they fetch the subject data.

I’ve submitted the above findings to hello@wanikani.com so, fingers crossed.

I shall err on the side of assuming no other reports have actually been made in future, hehe.

[TofuguKyle]

Thanks @Joeni !

@gunt3001 , did you write to us from a different email address than the one associated with your account? I can’t find an email from you or any other email mentioning the API issue aside from the one @tofugu-scott mentioned earlier in this thread.

I’ll also add that no one should feel like it’s a bother when they send us an email, so please write in even if you think the issue has been reported or otherwise

At the very least, multiple emails help us understand the impact

[Joeni]

@TofuguKyle

I’ll also add that no one should feel like it’s a bother when they send us an email, so please write in even if you think the issue has been reported or otherwise

flips back to section seven of the ITIL4 manual

That checks out and I should really have known better, I fear I did not deserve my 98% pass

@TofuguKyle

At the very least, multiple emails help us understand the impact

This also checks out… at the University of Bath, we understood the CrowdStrike incident very well indeed. So many emails.

[gunt3001]

@TofuguKyle

@gunt3001 , did you write to us from a different email address than the one associated with your account? I can’t find an email from you or any other email mentioning the API issue aside from the one @tofugu-scott mentioned earlier in this thread.

No, it should be from the same email as the one on my account, with subject line Bug report: subjects API endpoint returning wrong accepted_answer flag. Must have somehow got lost in the depths of the internet.

Anyways, thanks for the prompt fix. Happy holidays!

[Batsu]

Hope I’m not reopening this thread inappropriately, but I seem to still be having this issue today on Smouldering Durtles. I got two instances of the mixed-up on/kun readings (e.g. demanding the on’yomi for 横, which was never taught). This was an API issue so I’d be surprised if there was something I need to do on my end, but I’m on Durtles 1.1.8.

Thanks!

Tom

[simias]

You’ll have to “reset database” from the settings menu to refetch the data from the API.

[Joeni]

@Batsu

This was an API issue so I’d be surprised if there was something I need to do on my end, but I’m on Durtles 1.1.8.

Not a super big issue in this instance since I happened to make this thread too, but I’ll always ask that SD related comments go in the SD thread so I definitely see them

@simias got ya back here and just to expand - if your app last pulled the data you’re seeing while the API was still having issues, that ‘reset database’ option is needed to force the app to refresh the data, as it has no way to know the readings are still wrong.

[Batsu]

Thank you both for the quick replies!

T