FOUR-12686: Restart processmaker:consume command(s) when config changes

[runyan-co]

Issue

All ProcessMaker settings are persisted in the database, but are also set in the laravel config(). When the config is cached, it is stored in bootstrap/cache/config.php, which each instance of the app uses when booting up.

Currently, we restart the job queue by listening for config changes since it is a long-running command (php artisan horizon) and only reads from bootstrap/cache/config.php once when it starts.

When testing an Actions By Email feature, the settings changes which were made were not picked up by the (more recent) processmaker:consume artisan command, which is also long-running. This caused an exception to be thrown in the processmaker:consume command's process when the ABE email was attempted to be sent.

Solution

Call the kafka:restart-consumers command to restart all running commands to pick up the new configuration change.

Reproduction Steps

1. Using the latest version of ProcessMaker, install all enterprise packages
2. Ensure the nayra microservice is setup, connected, and functioning properly
3. Cache the configuration (php artisan config:cache)
4. Configure Actions by Email in the settings UI and ensure they are correct
5. Create a process which uses a simple ABE node or use this one
6. Start a new request with this process
7. Notice the ABE email never arrives
8. Check the logs of the processmaker:consume command and notice the errors

How to Test

Run through the reproduction steps 3-6 and ensure the processmaker:consume command is restarted

Related Tickets & Packages

• FOUR-12686

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[processmaker-sonarqube]

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

0.0% Coverage
0.0% Duplication