FOUR-30789: Fix Nayra REST host resolution for multitenant script execution

[eiresendez]

Issue & Reproduction Steps

FOUR-30789 tracks a multitenant server error while working with an Expense Report process created from a guide template.

The failure happens when a task edit flow triggers a synchronous php-nayra script execution. In the reproduced multitenant case, opening:

• https://processmaker-b.test/tasks/40/edit

can trigger the failing endpoint:

• POST https://processmaker-b.test/api/1.0/scripts/execute/26?task_id=40

Root cause: when the app switches tenant context, app.instance changes. The php-nayra runner then tried to resolve or start a tenant-specific Nayra Docker container instead of using the configured NAYRA_REST_API_HOST. That can make the script execution endpoint fail even though the shared Nayra REST service is configured and available.

The fix also preserves the single-tenant path, where this endpoint continues to work:

• POST https://processmaker.test/api/1.0/scripts/execute/40?task_id=574

Solution

• Make NAYRA_REST_API_HOST take priority when resolving the Nayra base URL.
• Keep the legacy Docker behavior when NAYRA_REST_API_HOST is not configured: use cached Nayra IPs when available, or bring up Nayra before resolving the Docker URL.
• Prevent the REST-host path from falling back to tenant Docker startup when the configured REST host is unreachable; it now fails with a clear ScriptException.
• Add PHPUnit regression coverage for REST-host priority and the legacy Docker fallback paths, so the fix remains backward compatible.

How to Test

• Automated: ./vendor/bin/phpunit tests/unit/ProcessMaker/Models/ScriptDockerNayraTraitTest.php
• Result: OK (5 tests, 14 assertions)
• Manual multitenant verification: with NAYRA_REST_API_HOST configured, open https://processmaker-b.test/tasks/40/edit and confirm POST /api/1.0/scripts/execute/26?task_id=40 returns 200.
• Manual single-tenant verification: open https://processmaker.test/tasks/575/edit and confirm POST /api/1.0/scripts/execute/40?task_id=574 still returns 200.

Related Tickets & Packages

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

ci:deploy
ci:multitenancy
ci:k8s-branch:fix-multitenancy
.

[processmaker-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[Kookster310]

QA server K8S was successfully deployed https://tenant-1.ci-87f9422be1.engk8s.processmaker.net

[eiresendez]

Thanks, Nolan, for generating the QA CI server:
https://tenant-1.ci-87f9422be1.engk8s.processmaker.net/tasks/3747/edit

After running the same test performed on my local using the route above, the fix is still not correct and the issue is reproducible in QA. The following endpoint is returning HTTP 500 errors:

• POST https://tenant-1.ci-87f9422be1.engk8s.processmaker.net/api/1.0/scripts/execute/42?task_id=3746

I think I may need the exact configuration from a real multitenant production environment in order to validate and provide an accurate fix. I will try to get that again.

cc: @nolanpro @sanjacornelius