Plugin compatibility with queue jobs on CLI mode

[touhidurabir]

With the release of 3.4 we have queue jobs that can run in several way as

1. through JobRunner on regular web request cycle
2. through Cron Jobs on CLI mode
3. though Worker Thread on CLI mode

While the best approach to run jobs via the CLI mode (Cron Job /Worker Thread), this present a compatibility issue with the plugin code execution . Our plugins has extensive implementation of following code such as

public function register($category, $path, $mainContextId = null)
    {
        if (parent::register($category, $path, $mainContextId)) {
            if ($this->getEnabled($mainContextId)) {

in the above code, the getEnabled method expect the information of context which is unavailable in the CLI mode as a separate app instance boot in the CLI mode without the context details . This cause plugin's code not to run and not to get desired outcome . For example, on the metadata update of a submission, if there is any search plugin installed that is supposed to run, it will fail because of above pattern . One such issue has already been registered at #9345.

Possible Solutions

1. Attach the context information at the job registration time to the job payload and dynamically set the context information when jobs get picked and clear that context information right after job complete processing / failed to process . This will not impact jobs serialization as context information not attach to serialized data but to core payload as an extra information . However this is not a very intuitive or easy to understand solution and add quite a bit code complexity to job execution process . A PR already done for this approach at pkp/pkp-lib#9345 added ability to retrive context for jobs on CLI session #9463 .

2. Update the plugins code to get rid of the implementation of getEnabled method and only depend on parent::register($category, $path, $mainContextId) . But this present another problem associated with the plugin enable/disable settings as if plugin is disable for some context, it will still continue to run .

3. Enable passing the context information on CLI mode . This will be a challenging one but probably the best possible solution .

[jonasraoni]

Hmm, I see this as part of a global long outstanding issue, which will require stop depending directly on the request, especially to retrieve a user/context, and pass resources down the road (or load through the container).