How to clean up non-completed Task Queue records in Mendix?

0
We are looking for a recommended way to clean up Task Queue records that are not in a completed state, specifically:AbortedFailedIncompatibleThe standard processed task cleanup handles processed Task Queue records, but what is the recommended approach for cleaning up these non-completed records?Is there any Mendix Runtime setting or built-in cleanup mechanism for these statuses, or should this be handled through a custom cleanup implementation?Also, are there any risks or considerations before deleting these records?
asked
3 answers
0

Hello,

You can add your custom microflow logic as follows :

Retrive Processed Queue Task List from database, by adding respected QueueTaskStatus constraint and delete the list accordingly

answered
0

Hi Chaitanya,

Is there a built-in cleanup?
Not for these statuses. The runtime cleanup (com.mendix.core.ProcessedTasksCleanupAge and com.mendix.core.ProcessedTasksCleanupBatchSize) removes only Completed records from System.ProcessedQueueTask. Failed, Aborted and Incompatible records stay until you remove them yourself.

Recommended approach: a custom cleanup
Create a scheduled event that runs a microflow which:

  1. Retrieves System.ProcessedQueueTask objects where Status is Failed, Aborted or Incompatible and the record is older than your retention period (for example 30 days, based on Finished).

  2. Deletes them in batches (for example 1,000 at a time, looping until none are left) to avoid long transactions and memory problems.

  3. Runs outside business hours.

The Task Queue Helpers module from the Marketplace also has maintenance microflows you can reuse.

What to check before deleting

  • Failed: the task hit an error and won’t be retried, so that work was never done. Check the ErrorMessage and rerun or fix the data first.

  • Incompatible: the task never ran, because the microflow was renamed or removed, or its parameters changed after the task was queued. Confirm the work isn’t still needed.

  • Aborted: usually safe to delete. These are history entries created when a node went down, and the task itself was retried on another node.

  • Only delete from ProcessedQueueTask. Never delete from or write to System.QueuedTask, because that holds tasks that are still waiting or running.

  • If you need the records for auditing, export or archive them before deleting.

Hope this helps! If this solution works for you, kindly mark it as the accepted answer so it can help others facing the same issue.

answered
0

Hi Chaitanya,

In addition to a Scheduled Event cleanup, it is worth monitoring the database growth caused by System.ProcessedQueueTask, especially in production environments with high task volumes.

From a database perspective:

  • Large numbers of Failed, Aborted, and Incompatible records can increase table size and affect query performance when administrators review task history.

  • If the table grows into millions of records, database maintenance operations such as backups, statistics updates, and index scans may take longer.

  • A periodic cleanup strategy (for example, retaining only the last 30-90 days of non-completed tasks) helps keep the table manageable.

For on-premise or self-managed databases (PostgreSQL, SQL Server, etc.), after substantial deletions you may also need normal database maintenance activities such as:

  • PostgreSQL: VACUUM / VACUUM ANALYZE

  • SQL Server: Index rebuild/reorganize and statistics updates

However, I would still recommend performing the deletion through Mendix (microflow or scheduled event) rather than executing direct SQL DELETE statements against Mendix system tables, since direct database changes are not officially supported and bypass runtime consistency checks.

A practical approach is:

  1. Retain recent Failed/Incompatible records for troubleshooting.

  2. Archive important error details if required.

  3. Delete old records via a Scheduled Event in batches.

  4. Include the table in regular database maintenance reviews if task volume is high.

This helps prevent unnecessary growth of the System.ProcessedQueueTask table while keeping enough history available for support and root-cause analysis.

answered