Reported by @peterlcsteele, in the scorm_set_score task - if the database transaction saving SCORM elements is slow, and the task runner is fast, then the task can try to run on an element that isn't in the database yet. Because the task runner has a different DB connection to the daphne server, it doesn't see the uncommitted transaction.
I think the most robust solution to this is to re-fetch the element when the task starts, and if it doesn't exist, schedule the task to run again a bit later (with a limit on the number of times it can run).
Reported by @peterlcsteele, in the
scorm_set_scoretask - if the database transaction saving SCORM elements is slow, and the task runner is fast, then the task can try to run on an element that isn't in the database yet. Because the task runner has a different DB connection to the daphne server, it doesn't see the uncommitted transaction.I think the most robust solution to this is to re-fetch the element when the task starts, and if it doesn't exist, schedule the task to run again a bit later (with a limit on the number of times it can run).