I would add a field to track the highest SRS level you’ve achieved, and then you could promote/demote anywhere up to that level.
Oh boy, that would be so nice…
>Burn everything
>Reset everything to Apprentice 1
>Send everything back to burned
I’ve noticed that for a lot of kanji subjects delivered by the API, some of the visually similar subject IDs are duplicated. For example for subject 933, the kanji “Clear Up”:
“visually_similar_subject_ids”: [
864,
891,
1386,
1356,
1052,
1370,
2319,
864,
891,
1386,
1356,
1052,
1370,
2319
],
Not a big deal, obviously, but I wanted to let you know just in case.
Ahh yeah. We should remove the dupes. Thanks for letting us know. Will update ya when it is fixed.
Some updates coming around 2019-10-07T18:00:00Z:
All of the line items are live now.
I may have to be a bit of an annoying nag here… . This is already live? I just did a test where I did an offline review last night and submitted it just now, and I’m still seeing the old behaviour. This is on a test account that’s on level 2, so the SRS interval for an Apprentice I item is 2 hours.
I’m on UTC+2, so 06:31 local time is 04:31 UTC.
Request
10-08 06:31:52.668 7751-8409/com.the_tinkering.wk D/ReportSessionItemTask: Posting: https://api.wanikani.com/v2/reviews
10-08 06:31:52.788 7751-8409/com.the_tinkering.wk D/ReportSessionItemTask: Request body: {
"review" : {
"created_at" : "2019-10-07T20:40:10.413000Z",
"incorrect_meaning_answers" : 6,
"incorrect_reading_answers" : 0,
"subject_id" : 48
}
}
As you can see, the review was created at 20:40 UTC last night. The response was:
Response
10-08 06:31:53.029 7751-8409/com.the_tinkering.wk D/ReportSessionItemTask: Response code: 201 Created
10-08 06:31:53.089 7751-8409/com.the_tinkering.wk D/ReportSessionItemTask: Response body: {
"id" : 808872554,
"object" : "review",
"url" : "https://api.wanikani.com/v2/reviews/808872554",
"data_updated_at" : "2019-10-08T04:31:25.794292Z",
"data" : {
"created_at" : "2019-10-07T20:40:10.413000Z",
"assignment_id" : 146014097,
"subject_id" : 48,
"starting_srs_stage" : 3,
"starting_srs_stage_name" : "Apprentice III",
"ending_srs_stage" : 1,
"ending_srs_stage_name" : "Apprentice I",
"incorrect_meaning_answers" : 6,
"incorrect_reading_answers" : 0
},
"resources_updated" : {
"assignment" : {
"id" : 146014097,
"object" : "assignment",
"url" : "https://api.wanikani.com/v2/assignments/146014097",
"data_updated_at" : "2019-10-08T04:31:25.787310Z",
"data" : {
"created_at" : "2019-08-22T04:43:26.857248Z",
"subject_id" : 48,
"subject_type" : "radical",
"srs_stage" : 1,
"srs_stage_name" : "Apprentice I",
"unlocked_at" : "2019-10-05T22:13:16.142737Z",
"started_at" : "2019-10-06T02:23:40.821815Z",
"passed_at" : null,
"burned_at" : null,
"available_at" : "2019-10-08T06:00:00.000000Z",
"resurrected_at" : null,
"passed" : false,
"hidden" : false
}
},
"review_statistic" : {
"id" : 137190448,
"object" : "review_statistic",
"url" : "https://api.wanikani.com/v2/review_statistics/137190448",
"data_updated_at" : "2019-10-08T04:31:25.806410Z",
"data" : {
"created_at" : "2019-08-22T04:46:02.320799Z",
"subject_id" : 48,
"subject_type" : "radical",
"meaning_correct" : 3,
"meaning_incorrect" : 6,
"meaning_max_streak" : 2,
"meaning_current_streak" : 1,
"reading_correct" : 3,
"reading_incorrect" : 0,
"reading_max_streak" : 3,
"reading_current_streak" : 3,
"percentage_correct" : 50,
"hidden" : false
}
}
}
}
The review record was created at 20:40 UTC as indicated by the request, but the available_at is set to 06:00 which is 2 hours from the top of the hour of the submission time, not the created_at time.
Odd. We have tests in place.
I’ll review the code and tests tomorrow.
What param key are you using to pass in the timestamp?
I was able to identify the issue. Will have a fix out tomorrow. Sorry about that. Thanks for letting us know.
For a review, created_at
. For a lesson, started_at
. The exact request body for my example request (which was a review, I haven’t tried a lesson yet):
{
"review" : {
"created_at" : "2019-10-07T20:40:10.413000Z",
"incorrect_meaning_answers" : 6,
"incorrect_reading_answers" : 0,
"subject_id" : 48
}
}
Thanks, glad I wasn’t just doing a bad request here
Fix is making its way out now. Give it five minutes.
Have you had any problems with lessons? Looks like lesson registration should be fine.
Ah, the joys of timezones… Just getting out of bed here in euro country…
Reviews seem to be good now . I haven’t tested lessons recently, so I don’t know about those yet. I never bothered to make a test fixture for this particular problem, so I’m actually just using my app in airplane mode to test this . I just did an offline lesson, I’ll know if it works later this morning and i’ll follow up then.
Yep, lessons look fine to me as well!
Hi @viet, I hope you’re not too tired of me yet…
With more offline mode testing, I’m running into another problem. This time, it’s with the unlocked_at timing. If I submit a review with a created_at timestamp in the past, and that review is a review that unlocks new assignments for my account, then the unlocked_at timestamp for those new assignments is the timestamp the review was submitted, not the created_at timestamp.
In this case, the new available_at of the original review assignment is correctly calculated, only the unlock process that cascades from there doesn’t seem to take into account the review’s created_at timestamp, but just uses the current timestamp instead.
After some discussion, me writing a post that had a nice version of “working as expected”, then realizing that we could make it work better… well, we’ll work on it. It’s a reasonable change, and not a ton of change to the code.
Thanks! I was sad about having to disable that part of my app, I look forward to turning it back on again.
At the risk of being greedy (and please keep in mind I’m a big boy who can take no for an answer if need be), will that unlock change also cover level-ups? Specifically, if I guru that one last kanji, will the unlocked items for the next level also have the unlocked_at set based on the review’s created_at timestamp? I know the speed demons really want to punch in their new radicals ASAP…
I dug into the code, and it might be more complicated than I anticipated — those pesky edge cases! I’ll let you know what I find in the next couple days.
One thing to think about is the source of truth for events and data around those events. Review and lesson times reported from someplace else via the API make a ton of sense to record and accommodate — that’s when the review was done, and we want to make sure that available_at dates reflect that reality.
Unlocks, though, should only happen on WaniKani after we know you’ve done a review.
We’ve talked/continue talking about all kinds of offline functionality, and we’ve talked about all kinds of levels.
At one extreme is connecting once, getting all the information from WK, and then being able to do any number lessons and reviews without ever connecting again. That assumes that all of the application logic is available while you’re offline — unlocks, level ups, all that stuff, and that you’re confident that the logic . That ignores a lot of checks for subscription status, updated subject information, new audio, all that stuff.
We think a more reasonable approach is to allow people to do the lessons and reviews they had the last time they connected. That supports flaky or slow network connections (offline for 1 second) or on a plane flight (offline for a few hours or a day), but doesn’t let someone proceed through levels or anything like that. It simplifies the logic in the client and enforces regular checkins for new content and subscription status (which needs to be respected).
With that in mind, I might come back and say that we’re keeping the original timestamps.
If offline means “work through the queue you have”, it doesn’t really matter what the unlocks are listed as for items and levels — new content isn’t available until the reviews are reported to the server. You either wind up with a funny gap between the last review and the unlocked subject/level, or a funny gap between the unlocked subject/level and the first time you see them in lessons. Either way, the new stuff won’t show up on other clients until those reviews get sent in.
Those sound like strong opinions (they are), but they’re (mainly) loosely held. We’d love to hear thoughts and opinions, though!