FOUR-21936: Error 404 when importing old processes with sub processes

[eiresendez]

Issue & Reproduction Steps

Previously, when a process was not found in the api/1.0/processes/{process}/, the app automatically threw a ModelNotFoundException, which was handled globally by the Handler.php. However this approach led to the API response being redirected to the fallback route, returning a generic “Not Found” message instead of a more specific error.

1. Make a GET request to /api/processes/{invalid_id} with a non-existent processId.
2. The API returns a 404 error with a generic fallback message instead of a specific response.

Solution

• Removed route model binding (Process $process) in the show() method.
• Now using Process::find($processId), which returns null instead of throwing an exception.
  • If the process is not found, the API responds with a custom JSON message:
• This prevents the exception from being caught by the global Handler.php, ensuring the correct error response is returned.

How to Test

Follow the reproduction steps from JIRA ticket.

Expected behavior: The API now returns a clear and consistent error message without relying on the exception handler.

Related Tickets & Packages

• FOUR-21936

.

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.

[eiresendez]

NOTE: The failing tests are not related to the changes in the PR. The issue has already been reported here: https://processmaker.atlassian.net/browse/FOUR-21949

[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

[eiresendez]

Issue & Reproduction Steps

Previously, when a process was not found in the api/1.0/processes/{process}/, the app automatically threw a ModelNotFoundException, which was handled globally by the Handler.php. However this approach led to the API response being redirected to the fallback route, returning a generic “Not Found” message instead of a more specific error.

1. Make a GET request to /api/processes/{invalid_id} with a non-existent processId.
2. The API returns a 404 error with a generic fallback message instead of a specific response.

Solution

• Removed route model binding (Process $process) in the show() method.
• Now using Process::find($processId), which returns null instead of throwing an exception.
  • If the process is not found, the API responds with a custom JSON message:
• This prevents the exception from being caught by the global Handler.php, ensuring the correct error response is returned.

How to Test

Follow the reproduction steps from JIRA ticket.

Expected behavior: The API now returns a clear and consistent error message without relying on the exception handler.

Related Tickets & Packages

• FOUR-21936

.

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.

[eiresendez]

NOTE: The failing tests are not related to the changes in the PR. The issue has already been reported here: https://processmaker.atlassian.net/browse/FOUR-21949

[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

[eiresendez]

Issue & Reproduction Steps

Previously, when a process was not found in the api/1.0/processes/{process}/, the app automatically threw a ModelNotFoundException, which was handled globally by the Handler.php. However this approach led to the API response being redirected to the fallback route, returning a generic “Not Found” message instead of a more specific error.

1. Make a GET request to /api/processes/{invalid_id} with a non-existent processId.
2. The API returns a 404 error with a generic fallback message instead of a specific response.

Solution

• Removed route model binding (Process $process) in the show() method.
• Now using Process::find($processId), which returns null instead of throwing an exception.
  • If the process is not found, the API responds with a custom JSON message:
• This prevents the exception from being caught by the global Handler.php, ensuring the correct error response is returned.

How to Test

Follow the reproduction steps from JIRA ticket.

Expected behavior: The API now returns a clear and consistent error message without relying on the exception handler.

Related Tickets & Packages

• FOUR-21936

.

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.

[eiresendez]

NOTE: The failing tests are not related to the changes in the PR. The issue has already been reported here: https://processmaker.atlassian.net/browse/FOUR-21949

[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

[eiresendez]

Issue & Reproduction Steps

Previously, when a process was not found in the api/1.0/processes/{process}/, the app automatically threw a ModelNotFoundException, which was handled globally by the Handler.php. However this approach led to the API response being redirected to the fallback route, returning a generic “Not Found” message instead of a more specific error.

1. Make a GET request to /api/processes/{invalid_id} with a non-existent processId.
2. The API returns a 404 error with a generic fallback message instead of a specific response.

Solution

• Removed route model binding (Process $process) in the show() method.
• Now using Process::find($processId), which returns null instead of throwing an exception.
  • If the process is not found, the API responds with a custom JSON message:
• This prevents the exception from being caught by the global Handler.php, ensuring the correct error response is returned.

How to Test

Follow the reproduction steps from JIRA ticket.

Expected behavior: The API now returns a clear and consistent error message without relying on the exception handler.

Related Tickets & Packages

• FOUR-21936

.

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.

[eiresendez]

NOTE: The failing tests are not related to the changes in the PR. The issue has already been reported here: https://processmaker.atlassian.net/browse/FOUR-21949

[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

[eiresendez]

Issue & Reproduction Steps

Previously, when a process was not found in the api/1.0/processes/{process}/, the app automatically threw a ModelNotFoundException, which was handled globally by the Handler.php. However this approach led to the API response being redirected to the fallback route, returning a generic “Not Found” message instead of a more specific error.

1. Make a GET request to /api/processes/{invalid_id} with a non-existent processId.
2. The API returns a 404 error with a generic fallback message instead of a specific response.

Solution

• Removed route model binding (Process $process) in the show() method.
• Now using Process::find($processId), which returns null instead of throwing an exception.
  • If the process is not found, the API responds with a custom JSON message:
• This prevents the exception from being caught by the global Handler.php, ensuring the correct error response is returned.

How to Test

Follow the reproduction steps from JIRA ticket.

Expected behavior: The API now returns a clear and consistent error message without relying on the exception handler.

Related Tickets & Packages

• FOUR-21936

.

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.

[eiresendez]

NOTE: The failing tests are not related to the changes in the PR. The issue has already been reported here: https://processmaker.atlassian.net/browse/FOUR-21949

[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

[eiresendez]

Issue & Reproduction Steps

Previously, when a process was not found in the api/1.0/processes/{process}/, the app automatically threw a ModelNotFoundException, which was handled globally by the Handler.php. However this approach led to the API response being redirected to the fallback route, returning a generic “Not Found” message instead of a more specific error.

1. Make a GET request to /api/processes/{invalid_id} with a non-existent processId.
2. The API returns a 404 error with a generic fallback message instead of a specific response.

Solution

• Removed route model binding (Process $process) in the show() method.
• Now using Process::find($processId), which returns null instead of throwing an exception.
  • If the process is not found, the API responds with a custom JSON message:
• This prevents the exception from being caught by the global Handler.php, ensuring the correct error response is returned.

How to Test

Follow the reproduction steps from JIRA ticket.

Expected behavior: The API now returns a clear and consistent error message without relying on the exception handler.

Related Tickets & Packages

• FOUR-21936

.

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.

[eiresendez]

NOTE: The failing tests are not related to the changes in the PR. The issue has already been reported here: https://processmaker.atlassian.net/browse/FOUR-21949

[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

[eiresendez]

Issue & Reproduction Steps

Previously, when a process was not found in the api/1.0/processes/{process}/, the app automatically threw a ModelNotFoundException, which was handled globally by the Handler.php. However this approach led to the API response being redirected to the fallback route, returning a generic “Not Found” message instead of a more specific error.

1. Make a GET request to /api/processes/{invalid_id} with a non-existent processId.
2. The API returns a 404 error with a generic fallback message instead of a specific response.

Solution

• Removed route model binding (Process $process) in the show() method.
• Now using Process::find($processId), which returns null instead of throwing an exception.
  • If the process is not found, the API responds with a custom JSON message:
• This prevents the exception from being caught by the global Handler.php, ensuring the correct error response is returned.

How to Test

Follow the reproduction steps from JIRA ticket.

Expected behavior: The API now returns a clear and consistent error message without relying on the exception handler.

Related Tickets & Packages

• FOUR-21936

.

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.

[eiresendez]

NOTE: The failing tests are not related to the changes in the PR. The issue has already been reported here: https://processmaker.atlassian.net/browse/FOUR-21949

[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

[eiresendez]

Issue & Reproduction Steps

Previously, when a process was not found in the api/1.0/processes/{process}/, the app automatically threw a ModelNotFoundException, which was handled globally by the Handler.php. However this approach led to the API response being redirected to the fallback route, returning a generic “Not Found” message instead of a more specific error.

1. Make a GET request to /api/processes/{invalid_id} with a non-existent processId.
2. The API returns a 404 error with a generic fallback message instead of a specific response.

Solution

• Removed route model binding (Process $process) in the show() method.
• Now using Process::find($processId), which returns null instead of throwing an exception.
  • If the process is not found, the API responds with a custom JSON message:
• This prevents the exception from being caught by the global Handler.php, ensuring the correct error response is returned.

How to Test

Follow the reproduction steps from JIRA ticket.

Expected behavior: The API now returns a clear and consistent error message without relying on the exception handler.

Related Tickets & Packages

• FOUR-21936

.

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.

[eiresendez]

NOTE: The failing tests are not related to the changes in the PR. The issue has already been reported here: https://processmaker.atlassian.net/browse/FOUR-21949

[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