API data incorrect?

Looks good :thumbsup:

Curious, it might significantly reduce your load if you didn’t load the answer information via ajax when a review is guessed incorrectly. I mean loading it all at once (it shouldn’t be much extra data to send across the wire I would think, even if you sent them in groups of 10).

Is there a reason this isn’t done?

RIght I agree. But we are focusing on the top slowest and time consuming transactions. Those transactions don’t register anywhere near there.

We pushed out the fix for the n+1 and so far its purring nicely.


I started seeing this issue again this evening.

Yes, it’s not working again on one of my apps. Not yet tested second one.

Can you provide more context to the issue you are experiencing? I see the API is outputting the following at the timestamp of this post (retracted the user information):


And I did a manual SQL query for each key and they all check out. What is differing? What does our website minus all WK scripts say? Are those values okay?

Also checked the generated output bypassing the cache and its the same.

Right now I have this on the website:

This on the android app, Wanikani:

and this on the iPad Allicrab

All freshly updated (as far as I can tell)

Looking at the raw output of the API (on the API page), I can see that the data should be correct, so I’m not sure why both apps are not updating. Has the format changed in some way, so they’re not parsing it correctly?

Hold on a minute!

If I go to the API help page and look at the data in the sample response, the numbers are correct.

> “requested_information”: {
> “lessons_available”: 0,
> “reviews_available”: 53,
> “next_review_date”: 1498152686,
> “reviews_available_next_hour”: 10,
> “reviews_available_next_day”: 91

BUT, if I copy and paste the actual URL that’s supposed to deliver these numbers:

https://www.wanikani.com/api/user/MY USER ID HERE/study-queue

I get the incorrect figures that I see in my apps.

> “requested_information”:{“lessons_available”:0,“reviews_available”:0,“next_review_date”:1498122000,“reviews_available_next_hour”:7,“reviews_available_next_day”:120}}

So the API URL is still delivering the same results you got when you tested it nine hours ago, but the information displayed in the Help page is up to date. Caching??

All OK this morning.

@StevePaget: Yep, caching. We cleared up some lingering problems (read: typos) on our end late last night, and we’re hoping that resolves the count mismatches that people were seeing.

We’ve got one more change we’re pushing out early next week that we think we’ll make the app and API counts update much more rapidly when reviews are submitted.


Nothing better than that burning feeling of confidence in your stomach when an issue seems to resolve itself, huh?

EDIT: @oldbonsai were you guys using a messaging bus to update the counts before? Did you decide to move away from that architecture completely, or just make performance tweaks and/or reducing polling time?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.