Hmm.  So we don't expect chunking to always sum to the original count, because the course enrollment may have changed in the meantime.  And even if we were to put this in a single transaction and perform the queries, I believe we would still see the same behavior.  We are not running MySQL at the highest level of isolation, so such "phantom reads" can freely take place because the table range is not being locked.   And I don't think we want to do a select_for_update on the user table, as that would cause serious problems with the rest of the system.

So I would change the wording of the comment to reflect that the count may indeed change as users enroll or unenroll during the queuing.   The purpose of the original count is to estimate the number of subtasks needed to perform the requested task.  It is merely an approximation.