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

[eiresendez]

Issue & Reproduction Steps

FOUR-30789 tracks a multitenant server error while creating a new report from an Expense Report process generated from a Guide Template.

The failing flow triggers synchronous php-nayra script execution from the task edit/report flow. In QA, the endpoint still returned HTTP 500 after the first fix:

• POST /api/1.0/scripts/execute/42?task_id=3746

Root Cause

The original fix assumed real multitenant environments would provide NAYRA_REST_API_HOST, so the php-nayra runner could always prioritize that configured REST endpoint.

After comparing the local .env with a real production-like multitenant pod env, that assumption was wrong. The real config does not define NAYRA_REST_API_HOST. Instead, it uses remote Docker:

• MULTITENANCY=true
• PROCESSMAKER_SCRIPTS_DOCKER_HOST=tcp://qa-remotedocker:2375
• no NAYRA_REST_API_HOST

In that configuration, the old fallback still tried to resolve or start a tenant-specific Nayra container using the tenant-mutated app.instance, for example processmaker_3_nayra, then use Docker bridge/container IPs such as 172.x.x.x as the REST base URL.

That is not reliable for real multitenant deployments because the web app must call a reachable HTTP endpoint, not an internal Docker bridge IP. It also should not create a separate Nayra REST service per tenant when the request already carries script code, data, config, environment variables, and timeout.

Solution

• Keep NAYRA_REST_API_HOST as the highest-priority explicit override when configured.
• For real multitenant Docker configs without NAYRA_REST_API_HOST, resolve Nayra to a reachable endpoint:
  • local Docker: http://127.0.0.1:<nayra_port>
  • remote Docker: derive the host from PROCESSMAKER_SCRIPTS_DOCKER_HOST, for example http://qa-remotedocker:8080
• Normalize empty NAYRA_PORT values to 8080 so Docker does not publish Nayra on a random port.
• Use a stable shared Nayra container name for multitenant environments instead of a tenant-specific app.instance suffix.
• Cache the reachable Nayra endpoint as nayra_endpoint and invalidate it if the health check fails.
• Keep the previous NAYRA_REST_API_HOST behavior backward compatible.
• Make the trait dependency on ScriptExecutor explicit through getScriptExecutor() so static analysis no longer depends on an implicit private property from Base.
• Add regression coverage for real multitenant fallback behavior, remote Docker host resolution, stale endpoint invalidation, and REST-host priority.

How to Test

Automated:

• php -l ProcessMaker/Models/ScriptDockerNayraTrait.php
• php -l ProcessMaker/ScriptRunners/Base.php
• php -l tests/unit/ProcessMaker/Models/ScriptDockerNayraTraitTest.php
• ./vendor/bin/phpunit tests/unit/ProcessMaker/Models/ScriptDockerNayraTraitTest.php

Result:

• OK (9 tests, 21 assertions)

Manual multitenant verification:

• Use a multitenant env matching the production-like pod config where PROCESSMAKER_SCRIPTS_DOCKER_HOST is set and NAYRA_REST_API_HOST is not set.
• Reproduce the Expense Report Guide Template flow.
• Confirm POST /api/1.0/scripts/execute/... returns 200.
• Confirm logs no longer show tenant-specific Nayra Docker startup failures or ScriptDockerNayraTrait.php timeout while resolving container bridge IPs.

Related Ticket

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

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

[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

[Kookster310]

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

[Kookster310]

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

[Kookster310]

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

[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]

Closing this PR.

This PR went further into the multitenant fallback path without NAYRA_REST_API_HOST, but that area now needs more product/architecture direction because php-nayra is not compatible with the script executor microservice and only works on the EC2 Docker engine.

[nolanpro]

Related PR https://github.com/ProcessMaker/processmaker/pull/8713/changes