Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix masterylog end timestamp issues #12870

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

rtibbles
Copy link
Member

@rtibbles rtibbles commented Nov 21, 2024

Summary

  • Fixes bug and adds regression test to ensure the end_timestamp on masterylogs get properly updated after initialization
  • Adds tests for and updates behaviour to ensure that our upgrade machinery can handle compound version ranges
  • Adds upgrade function to remediate the masterylog end timestamp issues if the upgrade is from an affected Kolibri version
  • Updates any masterlogs whose end timestamp is the same as the start timestamp, as would be the case for those affected by this bug
  • Sets to the end timestamp of the most recent attempt (if any)
  • Otherwise set to the end timestamp of the content summary log

References

Fixes #12855

Reviewer guidance

Are all three cases needed? Possible we could just check attempts and then content summary log.

@github-actions github-actions bot added the DEV: backend Python, databases, networking, filesystem... label Nov 21, 2024
Copy link
Member

@nucleogenesis nucleogenesis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After looking through everything I don't know if I'm quite qualified to fully give this the Approval - just came out the other side of my review w/ some non-blocking questions about it so I'll leave approval to @jredrejo

The Django upgrade handling stuff might be a really interesting quick demo. Mostly curious about what parts of it are automagical and how - I went into this expecting it to be a part of a migration but seeing the upgrade.py it looks a lot more like a Django ™️ feature for handling upgrades.

@@ -57,3 +63,36 @@ def fix_duplicated_attempt_logs():
item and non-null masterylog_id.
"""
consolidate_quiz_attempt_logs(AttemptLog.objects.all())


@version_upgrade(old_version=">0.15.0,<0.18.0")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just makes it so that the function below is only run when the current version is between these versions? Like if you are going from >0.15.0,<0.18.0 to anything else, this will run?

If so then what if you're upgrading from 0.15.2 to 0.17.3, then you upgrade from 0.17.3 to >=0.18.x would this end up being run again?

Not that it'd matter since it'd basically do nothing in that case since it'd have been fixed already, I'm just asking out of curiosity.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, except this code only exists in 0.18.0, so I would be mystified if it managed to run in 0.17.3 :)

Comment on lines +409 to +417
@parameterized.expand(
[
("0.15.8", ">=0.15.8", True),
("0.15.7", ">=0.15.8", False),
("0.15.8a5", ">=0.15.8", False),
("0.15.9a5", ">=0.15.8", True),
("0.15.8a5.dev0+git.682.g0be46de2", ">=0.15.8", False),
("0.15.9a5.dev0+git.682.g0be46de2", ">=0.15.8", True),
("0.15.9", ">0.15.8", True),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it was a lot of fun to write out - were you able to generate & format this list somehow or did you have to do it all by hand?

Also - what's going on here in general? 😅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot autocompleted it for me mostly incorrectly, and then I corrected it.

This is a list of testing parameters (each tuple is a set of parameters for the test) - to verify the version range checking behaviour.

@rtibbles
Copy link
Member Author

The Django upgrade handling stuff might be a really interesting quick demo. Mostly curious about what parts of it are automagical and how - I went into this expecting it to be a part of a migration but seeing the upgrade.py it looks a lot more like a Django ™️ feature for handling upgrades.

It's a Kolibri ™️ feature for handling upgrades - mostly to do data migrations outside of the irritating straight jacket of the Django migration system - also because it's completely under our control, we can do non-Django operations in it, and also do the version control stuff specific to Kolibri.

Copy link
Member

@jredrejo jredrejo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code seems to work right and I see it correct. I have a couple of comments and would like to know your opinion before approving it.
Thanks!

@@ -611,7 +611,8 @@ def _update_and_return_mastery_log_id(
mastery_level=context["mastery_level"],
summarylog_id=summarylog_id,
)
update_fields = tuple()
update_fields = ("end_timestamp", "_morango_dirty_bit")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering if we could win some performance doing this inside the if time_spent_delta: condition below. If there has not been any difference of time we don't need to update it nor force morango to sync the dates

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that does make sense, and preserves the original intention of the code better.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated!



@version_upgrade(old_version=">0.15.0,<0.18.0")
def fix_masterylog_end_timestamps():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what would be now a KDP scenario?
There we have logs that have not run consolidate_quiz_attempt_logs mixed with logs that have it. And KDP identifies as 0.17.3, so it'd run fix_masterylog_end_timestamps

So, if I understand this correctly, in KDP we should either apply both upgrades, in order, or skip both. Correct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should skip both, yes. Let the Kolibris sort out their data before syncing to KDP.

@rtibbles
Copy link
Member Author

I think on reflection, coming to update this, I am going to remove the completion_timestamp condition - the attempt logs should cover it, and do so more accurately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DEV: backend Python, databases, networking, filesystem...
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MasteryLog is not updated when resumen a quiz
3 participants