Skip to content

Fix record deletion condition error in deleteinvalidconfiglog task - #3400

Open
Lai Wei (weilai-irl) wants to merge 3 commits into
MOODLE_500_STABLEfrom
wip-135949-m500
Open

Fix record deletion condition error in deleteinvalidconfiglog task#3400
Lai Wei (weilai-irl) wants to merge 3 commits into
MOODLE_500_STABLEfrom
wip-135949-m500

Conversation

@weilai-irl

Copy link
Copy Markdown
Collaborator

Fix local_o365 adhoc task deleting config_log records only when a matching logstore_standard_log row exists, causing infinite requeueing

The config_log deletion was nested inside the "if (!empty($logidstodelete))"
block, so the records were only removed when a matching record still existed
in logstore_standard_log.

That match is not guaranteed: old log records are removed every night by
\logstore_standard\task\cleanup_task according to the loglifetime setting,
while config_log is never purged by Moodle. When no match is found nothing is
deleted, the task then counts the records again, sees they are still there and
queues another adhoc task, which reads the same records and repeats.

Close the block after the logstore deletion so the config_log records are
always deleted. The execution time check and the pause between chunks move out
of the block as well, so they apply to every chunk.
$totaldeleted only counted logstore_standard_log rows deleted, so the
"Processed X records so far" message logged on hitting the execution
time limit stayed at 0 whenever a chunk had config_log rows with no
matching logstore_standard_log row - the common case this fix targets,
since old log entries are routinely purged by
\logstore_standard\task\cleanup_task while config_log is not. Count
config_log deletions too so the progress message reflects actual work
done.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

This pull request updates the local_o365 ad-hoc cleanup task to ensure invalid config_log records are deleted even when their corresponding logstore_standard_log entries no longer exist (e.g., after standard log cleanup), preventing the task from repeatedly re-queuing.

Changes:

  • Move config_log chunk deletion outside the conditional block so it runs regardless of whether matching logstore_standard_log rows were found.
  • Update deletion accounting so the task can report progress after deleting config_log rows as well.
  • Preserve the existing time-limit/requeue behavior while ensuring per-chunk progress occurs.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread local/o365/classes/task/deleteinvalidconfiglog.php Outdated
Review feedback on the time-limit mtrace message noted that
$totaldeleted combined logstore_standard_log and config_log deletion
counts, making "Processed X records" ambiguous about which table it
refers to. Split it into $totalconfigdeleted and
$totallogstoredeleted, and report both in the message.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

deleteinvalidconfiglog never deletes config_log records and keeps queueing new adhoc tasks

3 participants