summaryrefslogtreecommitdiff
path: root/addons/auth_crypt
diff options
context:
space:
mode:
authorAdrian Torres <adt@odoo.com>2017-12-01 14:15:42 +0000
committerGitHub <noreply@github.com>2017-12-01 14:15:42 +0000
commit3d1e23aaba2e220c7a92fb4323746a08a5a1b7ed (patch)
tree530dc488dbcd3b06d19df651af997679863f312e /addons/auth_crypt
parent441b2bf894c76efc035c0572a6659bdbd882beb2 (diff)
[FIX] *: Reset module states on registry init error
Commit 763d714 introduced cron job locking for databases which had modules with states set to 'to x', however if an installation/uninstallation/upgrade fails, the state will stay at 'to x', and it may stay in that state for an indefinite amount of time, meaning that cron jobs could stay locked forever. This commit fixes this in part by adding a cleanup function to loading.py that will be executed whenever load_modules fails, the function will change every 'to x' module to their original state, effectively unlocking the execution of cron jobs. This however only works to prevent "zombie" transient states for brand new databases, however for existing databases which already contain some modules in a zombie state it won't do anything unless a module is installed/uninstalled/upgraded, which may never happen. This is where the second part comes in (ir_cron.py), when failing to execute crons, we check if the failure was due to bad module state and if an arbitrary amount of time (5 hours as of this commit) has passed since the last time it was supposed to be executed, if it is the case, it means that the cron execution failed around 5 * 60 times (1 failure per minute for 5h) in which case we assume that the crons are stuck because the db has zombie states and we force a call to reset_module_states.
Diffstat (limited to 'addons/auth_crypt')
0 files changed, 0 insertions, 0 deletions