Fixes Error: Workflows with triggers, which have more than 65.535 parameters (or course IDs) with PostgreSQL throw an error (in all versions)

[mikeJKU]

v2

• Extends last partial solution
• Split db query for each trigger (= calculating trigger to courses) into "chunked sub queries" (for each trigger), based on the amount of params
• Set max params for each trigger query to 65.535 (for PostgreSQL)
• Should be final solution

v1 (Issue: #243)

• Split single db query for calculating "triggers to courses" into a single db query for each trigger to prevent error, if more than 65.535 courses are calculated
• Not the best solution, because it only works if no trigger has more than 65.535 courses (with PostgreSQL)

🔀 Purpose of this PR:

• Fixes a bug
• Updates for a new Moodle version
• Adds a new feature of functionality
• Improves or enhances existing features
• Refactoring: restructures code for better performance or maintainability
• Testing: add missing or improve existing tests
• Miscellaneous: code cleaning (without functional changes), documentation, configuration, ...

---

📝 Description:

The core issue is that all triggers are "calculated" in one database query to produce a single moodle_recordset as the result. If the combined triggers of a workflow contain more than 65.535 parameters (or course IDs) using PostgreSQL an error is thrown. The following screenshot shows the error when a workflow (with more than 65.535 parameters) is shown with version v4.4-r1.

The next screenshots show the same error with version v5.2-r1.

A moodle_recordset can only be used or iterated through once. After that the results are no longer available and there is no way to merge multiple moodle_recordsets.

v1: (Issue: #243)
To address this I created a "helper class" that behaves like a moodle_recordset and allows moodle_recordsets to be added to it. If a moodle_recordset is added an intersection is created between the existing and the new moodle_recordset and this intersection is stored in the class. The exception is the first added moodle_recordset, which is entirely stored as the starting point.

This makes it possible to execute a separate database query for each trigger while still obtaining a single moodle_recordset as the final result. However, the issue reoccurs if a single trigger exceeds the 65.535 parameters (or course IDs) limit (with PostgreSQL). This is the reason why this bugfix is an interim solution only and i didn't make a pull request so far. A complete solution would involve splitting all parameters from all triggers into chunks smaller or equal to 65.535 and then performing a database query for each of these chunks.

v2:
This extension of v1 addresses the issue of the bugfix where the original error reoccurs if a single trigger exceeds 65.535 parameters or course IDs. Now, the variable $maxparams defines the upper limit for the parameters and can be adapted for all databases. If this limit is exceeded for a trigger, the parameters are split into smaller chunks (, based on the upper limit). Additionally, the (partial) query of the affected trigger is reconstructed and filled with the corresponding "chunk parameters." These new "chunk pairs" then replace the original (partial) query and parameters of the trigger in the form of sub-arrays. Subsequently, a separate query is executed for each element of the sub-array and the results are stored in the same structure.

Similarly, the constructor of the "helper class" (, which is required to simulate a final moodle_recordset) has been extended to recognize these sub-arrays with "chunk results." If this is the case, all results or moodle_recordsets of a "chunk result" are first aggregated into a single result, which is then added to build (and store) the intersection with the existing result of the triggers. This should be the final solution for this problem. The current solution has only been implemented for tool_lifecycle v4.5 (v4.5-r4 2025050403), v5.0 (v5.0-r3 2025102302) & v5.2 (v5.2-r1 2026060102).

In short: If the parameter limit per trigger is exceeded, these queries are split into smaller queries and their results are reassembled before determining the intersection with the remaining triggers.

This error occurs in older versions as well as in the new 5.2 version. I have adapted the method get_course_recordset() in the file classes/processor.php and added a new class called intersectedRecordset in the classes/local/ dir.

---

📋 Checklist

• I have phpunit and/or behat tests that cover my changes or additions.
• Code passes the code checker without errors and warnings.
• Code passes the moodle-ci/cd pipeline on all supported Moodle versions or the ones the plugin supports.
• Code does not have var_dump() or var_export or any other debugging statements (or commented out code) that
  should not appear on the productive branch.
• Code only uses language strings instead of hard-coded strings.
• If there are changes in the database: I updated/created the necessary upgrade steps in db/upgrade.php and
  updated the version.php.
• If there are changes in javascript: I build new .min files with the grunt amd command.
• If it is a Moodle update PR: I read the release notes, updated the version.php and the CHANGES.md.
  I ran all tests thoroughly checking for errors. I checked if bootstrap had any changes/deprecations that require
  changes in the plugins UI.

---

🔍 Related Issues

• Related to Error: Workflows with triggers, which have mor than 65.535 paramaters (or course IDs) throw an error (in all versions) #243

---