Release/2.0.x - Arches 8.0.x, Vue/Workflow components

[bferguso]

Release of arches common for:

• Arches Core v8.0.x
• Includes updates for BCRHP & BCFMS workflows

Depending on the stability of Arches 8.1.x, released in March 2026, BCRHP & BCFMS should be migrated to 2.1.x.

This supersedes dev/2.0.x_merge_1.3.0

In general, the fix is to avoid including raw exception messages (str(e)) in responses returned to clients. Instead, log the detailed exception (possibly with a stack trace) on the server, and return a generic, user-friendly message that does not reveal implementation details.

For this specific file, we should update the except urllib3.exceptions.HTTPError as e: and except urllib3.exceptions.RequestError as e: handlers. Both currently log str(e) and also embed str(e) into the JSON response sent to the user. We can keep the detailed logging exactly as-is (or even improve it later), but change the JsonResponse payloads to use generic messages like "Error fetching data from external API" and "Request error while fetching data from external API", without interpolating str(e). That ensures no exception/stack-trace-like content is exposed, while preserving the existing HTTP status codes and overall behavior.

Concretely:

• In bcgov_arches_common/views/api/pmbc.py, in the PMBCDataView.get method:
  • At lines 99–102, replace the "error" field from f"Error fetching data from external API: {str(e)}" to a static string without str(e).
  • At lines 112–113, similarly replace f"Error fetching data from external API: {str(e)}" with a static message, e.g. "Error fetching data from external API".
• No new imports or helper functions are needed; we only adjust the JSON content.

In general, the fix is to stop including raw exception messages (str(e)) in HTTP responses and instead return generic, user-safe messages. Detailed error information should be logged on the server (as is already being done with logger.error(...)) but not exposed to clients.

The best targeted fix here is to adjust the error JSON in the problematic except blocks so that:

• The log messages remain unchanged and can still include str(e).
• The response body uses a generic description (for example: "Error fetching data from external API" or "An internal error occurred while contacting the external service") that does not include str(e).

Concretely, in bcgov_arches_common/views/api/pmbc.py within PMBCDataView.get:

• Update the except urllib3.exceptions.HTTPError as e block to remove str(e) from the response JSON, keeping it only in the log.
• Update the except urllib3.exceptions.RequestError as e block (the one flagged on line 111) similarly, replacing "error": f"Error fetching data from external API: {str(e)}" with a generic fixed string.
• Update the general except Exception as e block to avoid returning str(e) to the user as "Unexpected error: {str(e)}", and use a generic message instead.

No new methods or imports are needed: logging and JsonResponse are already imported, and logging calls already exist. We only alter the error message strings inside the JSON responses.

In general, to fix information exposure via exceptions, you should avoid sending raw exception messages or stack traces to the client. Instead, log the detailed error on the server (with stack trace if needed) and return a generic, user-friendly error message that does not reveal internal implementation details.

For this specific code, the best fix is to modify the final except Exception as e: block so that:

• The log call can still include diagnostic detail (optionally using exc_info=True to capture a stack trace on the server).
• The JsonResponse returned to the client does not interpolate str(e) and instead uses a generic message such as "An unexpected internal error occurred" (or similar). The pid field can safely remain as it is derived from the request and already returned elsewhere.

Concretely:

• In bcgov_arches_common/views/api/pmbc.py, lines 125–135 (the final catch-all except block) should be updated.
• Keep the logger.error call but improve it (e.g., exc_info=True).
• Change the "error" field in the JSON to a generic string, removing str(e).

No new imports are strictly required; we can reuse logging and JsonResponse already imported.