fix: V1 log API endpoints silently drop logs for deleted workflows

[MaxwellCalkin]

Summary

The V1 public API log endpoints (/api/v1/logs, /api/v1/logs/[id], /api/v1/logs/executions/[executionId]) use innerJoin with the workflow table, which silently drops all logs for workflows that have been deleted. This is inconsistent with the internal API endpoints (/api/logs, /api/logs/[id]) which correctly use leftJoin.

Impact:

• GET /api/v1/logs — omits logs for deleted workflows from the list (data silently disappears)
• GET /api/v1/logs/[id] — returns 404 for logs whose workflow was deleted
• GET /api/v1/logs/executions/[executionId] — returns 404 for executions whose workflow was deleted

Additionally, the [id] and executions/[executionId] endpoints join permissions via workflow.workspaceId, which would be null when the workflow is deleted — breaking the authorization check entirely. The internal API correctly uses workflowExecutionLogs.workspaceId for this.

Changes

• v1/logs/route.ts: innerJoin → leftJoin for workflow table; handle null workflowName/workflowDescription with fallback to 'Deleted Workflow'
• v1/logs/[id]/route.ts: innerJoin → leftJoin for workflow table; fix permissions join to use workflowExecutionLogs.workspaceId instead of workflow.workspaceId; handle null workflow fields in response
• v1/logs/executions/[executionId]/route.ts: same innerJoin → leftJoin and permissions join fix

All changes align the V1 public API with the patterns already used by the internal API (/api/logs/*).

Test plan

• Verify GET /api/v1/logs?workspaceId=... includes logs for deleted workflows
• Verify GET /api/v1/logs/[id] returns log data (not 404) when the workflow has been deleted
• Verify GET /api/v1/logs/executions/[executionId] returns execution data (not 404) when the workflow has been deleted
• Verify deleted workflow logs show "Deleted Workflow" as the workflow name

This PR was authored by Claude Opus 4.6 (AI), operated by @MaxwellCalkin

🤖 Generated with Claude Code

[cursor]

PR Summary

Medium Risk
Changes join/authorization conditions in public V1 log endpoints; while it fixes missing/404 results for deleted workflows, it could affect which logs are visible if workflowExecutionLogs.workspaceId data is inconsistent.

Overview
V1 log endpoints now preserve logs even when the referenced workflow has been deleted by switching workflow joins from innerJoin to leftJoin, avoiding silent omission/404s.

The [id] and executions/[executionId] endpoints also authorize via workflowExecutionLogs.workspaceId (instead of workflow.workspaceId), and responses include a fallback workflow summary/name ("Deleted Workflow") when workflow fields are null.

^{Written by Cursor Bugbot for commit 74ef139. This will update automatically on new commits. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 9, 2026 1:44am

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Truthiness check for deleted workflow detection is inconsistent

Low Severity

The deleted-workflow check in v1/logs/[id]/route.ts uses JavaScript truthiness (log.workflowName) while v1/logs/route.ts uses nullish coalescing (log.workflowName ?? 'Deleted Workflow'). An empty-string workflow name would cause the [id] endpoint to show 'Deleted Workflow' for an existing workflow, while the list endpoint would correctly pass the empty string through. The internal API uses log.workflowId for this check, which is more reliable since it comes from workflowExecutionLogs (set to null on delete) and isn't subject to empty-string falsiness.

Additional Locations (1)

• apps/sim/app/api/v1/logs/route.ts#L170-L171

 

[greptile-apps]

Greptile Summary

This PR fixes three V1 public API log endpoints (/api/v1/logs, /api/v1/logs/[id], /api/v1/logs/executions/[executionId]) so they no longer silently drop logs whose associated workflow has been deleted. The changes align these endpoints with the existing internal API behavior.

Key changes:

• innerJoin(workflow) → leftJoin(workflow) in all three endpoints, so logs are retained even when the workflow FK is null (set on delete).
• Permissions join updated from workflow.workspaceId to workflowExecutionLogs.workspaceId in [id] and executions/[executionId], fixing a broken authorization path for deleted-workflow logs (since workflow.workspaceId would be null after deletion).
• Null fallbacks added for workflow name/description when workflow is deleted ('Deleted Workflow' placeholder).
• The workflowExecutionLogs.workspaceId field is NOT NULL (stored at execution time, unaffected by workflow deletion), making it a stable authorization anchor.

Confidence Score: 5/5

• Safe to merge — correctly fixes a real data-visibility and authorization bug with no remaining issues.
• The PR correctly implements the fix for a well-defined problem: V1 log endpoints were using innerJoin which silently dropped logs for deleted workflows. The changes properly use leftJoin and correctly fix the broken permissions authorization path. The deleted-workflow handling is appropriate, and all three endpoints follow the same correct pattern established by the internal API. No functional issues or safety concerns remain.
• No files require special attention

Sequence Diagram

sequenceDiagram
    participant Client
    participant V1LogsAPI
    participant DB_workflowExecutionLogs
    participant DB_workflow
    participant DB_permissions

    Client->>V1LogsAPI: GET /api/v1/logs?workspaceId=...
    V1LogsAPI->>DB_workflowExecutionLogs: SELECT logs
    DB_workflowExecutionLogs-->>DB_workflow: LEFT JOIN (was innerJoin)
    Note over DB_workflow: Deleted workflow → null fields (not dropped)
    DB_workflowExecutionLogs-->>DB_permissions: INNER JOIN on workflowExecutionLogs.workspaceId
    Note over DB_permissions: Auth uses log's own workspaceId (was workflow.workspaceId)
    DB_permissions-->>V1LogsAPI: Results (includes deleted-workflow logs)
    V1LogsAPI-->>Client: { name: "Deleted Workflow" } for deleted workflows

Loading

_{Last reviewed commit: 74ef139}