feat: update jwt api - #630
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LP_User_Item_Quiz::get_results() caches what it calculates under "<quiz>/user/<user>/course/<course>". start_quiz() clears that key, but submit_quiz() never did, so the entry written while the attempt was still in progress — every question unanswered — outlived the submission. wp_cache_* is per-request on a plain install, which is why this stayed invisible; with a persistent object cache (LiteSpeed, Redis, Memcached) the stale entry survives and every read after the submit serves it. The symptom is a quiz answered in full that comes back 0%, "not passed", with all questions marked Skipped, while the /quiz/finish response itself carries the correct score. Reproduced on a live install: start → finish with no read in between returned 15.38% and read back 15.38%; the same flow with one read between start and finish returned 13.33% and read back 0% with all 15 questions empty. LP_User_Item_Quiz now owns the key and exposes clear_results_cache(), which submit_quiz() calls once the attempt is completed. instant_check_question() rewrites the same stored result, so it clears the cache too. Verified against a local install, scoring one request end to end: without the change the read after the submit reported 0% and 5 empty answers against a submit response of 80%; with it the read reports 80% and matches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LP_Abstract_User::finish_course() completes the enrollment through LP_User_Item::complete(), which writes straight to learnpress_user_items. That path never calls UserCourseModel::clean_caches(), so the model cached under "userCourseModel/find/<user>/<course>/lp_course" keeps reporting the enrollment as in progress. wp_cache_* is per-request on a plain install and the staleness dies with the request; with a persistent object cache (LiteSpeed, Redis, Memcached) it survives and every later read serves the pre-finish status. The symptom is a course finished successfully that still offers "Finish course", with the sidebar showing the old progress. Confirmed on a live install: the listing endpoint, which reads the row straight from SQL, reported finished/passed with an end time, while the single-course endpoint - which goes through UserCourseModel::find() - still reported enrolled/in-progress for the same enrollment. finish_course() now cleans the model cache once the row is written. Verified against a local install in a single request: without the change a read taken after the finish reported enrolled/in-progress against a row that already held finished/passed; with it the read matches the row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.