UN-1924 [FIX] Three small inconsistencies in the new terminal paths

The worker's COMPLETED arm wrote total_files=0 and left the other two counters NULL — the exact shape update_execution_completed exists to avoid, since a terminal row with a NULL failed_files reads as a clean success. Nothing ran, so both are now written as zero. Its ERROR arm named the reason under "message" while the function's other two ERROR returns use "error", so a consumer reading .get("error") to learn why an execution failed got None for this variant alone. When the all-rejected status write raises, the response carried no error at all, unlike the sibling staging-failure path — a bare 422 with no reason, while the row is still PENDING so a follow-up GET /status says something else. The swallowed exception is now reported. Also corrects a comment that claimed a field-scoped save() is safe against concurrent writers: it is, for the columns, but save() re-runs _handle_execution_cache() regardless of update_fields, which another comment in the same file already explains. No live bug at this call site — the row is freshly created and undispatched — but the comment said otherwise.
Deepak-Kesavan · Sep 1, 2026 · Sep 1, 2026 · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026
commit 81a9e6a951af806f4d156ed4cfdb15bf9f723a5b
diff --git a/backend/api_v2/deployment_helper.py b/backend/api_v2/deployment_helper.py
@@ -322,14 +322,19 @@ def execute_workflow(
             # Isolate the DB write the way the staging-failure path above does, so
             # the rate limit slot and staging dir are released even if it raises.
             execution = None
+            terminalise_error: str | None = None
             try:
                 execution = WorkflowExecutionServiceHelper.update_execution_completed(
                     str(execution_id),
                     total_files=len(file_objs),
                     failed_files=len(file_objs),
                 )
-            except Exception:
+            except Exception as error:
                 logger.exception(f"Failed to mark execution {execution_id} as COMPLETED")
+                # Kept for the response: the sibling staging-failure path reports
+                # str(error), and without it the caller gets a bare 422 while the
+                # row is still PENDING, so a follow-up GET /status contradicts it.
+                terminalise_error = str(error)
 
             APIDeploymentRateLimiter.release_slot(
                 str(api.organization.organization_id), str(execution_id)
@@ -377,6 +382,7 @@ def execute_workflow(
                     execution_status=(
                         execution.status if execution else ExecutionStatus.ERROR.value
                     ),
+                    error=terminalise_error,
                     result=api_results,
                 )
             ).data

diff --git a/backend/workflow_manager/workflow_v2/execution.py b/backend/workflow_manager/workflow_v2/execution.py
@@ -409,8 +409,13 @@ def update_execution_completed(
             execution.total_files = total_files
             execution.successful_files = 0
             execution.failed_files = failed_files
-            # Field-scoped, matching update_execution, so this cannot clobber the
-            # status write or anything a concurrent writer touched.
+            # Field-scoped, so the status column and anything a concurrent writer
+            # touched are left alone. Note this is scoped to the DB row only:
+            # WorkflowExecution.save() re-runs _handle_execution_cache() whatever
+            # update_fields says, republishing this object's in-memory status to
+            # the Redis cache — see the fuller account in
+            # update_execution_queue_message_id. Harmless here because the row is
+            # freshly created and undispatched, so no worker can have moved it on.
             execution.save(
                 update_fields=[
                     "total_files",

diff --git a/workers/api-deployment/tasks.py b/workers/api-deployment/tasks.py
@@ -247,7 +247,10 @@ def _unified_api_execution(
                 return {
                     "execution_id": execution_id,
                     "status": "ERROR",
-                    "message": error_message,
+                    # "error", matching this function's other ERROR returns; a
+                    # consumer reading .get("error") to learn why gets None if
+                    # this one names it something else.
+                    "error": error_message,
                     "files_processed": 0,
                 }
 
@@ -258,6 +261,11 @@ def _unified_api_execution(
                 execution_id=execution_id,
                 status=ExecutionStatus.COMPLETED.value,
                 total_files=0,
+                # Written explicitly: a terminal row whose counters are NULL
+                # reads as a clean success, which is the shape update_execution_
+                # completed exists to avoid. Nothing ran, so both are zero.
+                successful_files=0,
+                failed_files=0,
             )
             if pipeline_id:
                 api_client.update_pipeline_status(