defect/FOUR-17640: Script execution is now halted when timeout is reached

[TinCodes]

Tickets Solved by this PR:

• https://processmaker.atlassian.net/browse/FOUR-17640

Solution

• Changed the timeout effect to 'kill' whenever the timeout is reached.

How to Test

1. Create a script
2. Use a sleep() function set to 20 seconds
3. Save the script
4. Edit the script settings so that the script timeout is 5 seconds
5. Open a terminal
6. Run the script and while it is running, use the command docker ps multiple times in the newly-opened terminal to verify that the execution is halted.

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]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[gproly]

"Changing -s 9 to -k 1s: Key Considerations"

Thank you for the change. Using -k 1s instead of -s 9 prioritizes an orderly shutdown, but there are some important points to verify to avoid potential issues:

1. Process Compatibility with SIGTERM:

   • Ensure the process being managed is designed to handle signals like SIGTERM. If the process ignores or doesn’t handle this signal properly, the change might introduce unnecessary delays without practical benefit.

2. Appropriate Grace Period:

   • The 1-second (1s) grace period might be insufficient or excessive depending on the process load or logic. Consider validating or adjusting this time based on real-world scenarios.

3. Impact on Critical Processes:

   • If the context requires immediate termination due to critical risks (e.g., resource locks or high availability), switching to -k 1s might not be appropriate.

Suggestion:
Test the behavior to ensure that using -k 1s meets functional requirements and doesn’t introduce risks like prolonged delays or unexpected blockages. If it’s not feasible to guarantee proper SIGTERM handling, it might be safer to stick with -s 9.

Thank you for ensuring this change is robust!

[TinCodes]

Hi @gproly,

The behavior was tested by @nolanpro and me with script executors and it seems to work fine. Please note that in the future we will start using the script microservice so this change may not be needed for very long.

[gproly]

I understand

[gproly]

approved