refresh_mod_calendar_events_task adhoc task execution is requested from upgrade.php, this is practically the same than to call an API function. We usually add a comment on functions that are called from upgrade so devs are careful when they modify them. I would suggest that we do the same in this case and this is a pity because all $modname_refresh_events functions are called from refresh_mod_calendar_events_task and I don't know to what extend they may be changed in future. Bug fixes to those functions should not be a problem, but we may have a problem if in future we are required to add code changes because of db scheme changes. When someone upgrades to 3.1 from 3.5 (where we hypotetically add a new field to mod_assign table that is checked in assign_refresh_events) the upgrade process will break because when this 3.3 upgrade step is executed the 3.5 new field is not part of the db scheme yet.

I can only think of 2 solutions:

1. Update the upgrade step so it replicates the same process all xxx_refresh_events go through (kind of duplicating it)
2. Flag the adhoc task + all xxx_refresh_events as dependant on 3.3 upgrade steps, blocking important changes to these functions, if in future there are important changes these functions need we will have to duplicate them and this will be a problem because we are already calling these functions from functions like set_coursemodule_name

I would vote for #1