feat(core): Add log streaming events for executions #23372
Conversation
…low execution (PAY-2936) - Add 'execution-deleted' event when user deletes executions - Add 'workflow-executed' event when user manually runs or retries workflow - Emit events with user context for audit logging - Add comprehensive unit tests for both events
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
1 issue found across 8 files
Prompt for AI agents (all 1 issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.
<file name="packages/cli/src/executions/execution.service.ts">
<violation number="1" location="packages/cli/src/executions/execution.service.ts:335">
P2: Audit event may log empty `executionIds` when deletions occur via `deleteBefore` filter. Consider either returning deleted IDs from the repository or including `deleteBefore` in the event payload to provide a complete audit trail.</violation>
</file>
Reply to cubic to teach it or ask questions. Re-run a review with @cubic-dev-ai review this PR
|
E2E Tests: n8n tests passed after 4m 25s Run Details
This message was posted automatically by
currents.dev | Integration Settings
|
This comment has been minimized.
This comment has been minimized.
…lete audit trail When executions are deleted via date filter (deleteBefore), the executionIds array would be empty. Including deleteBefore in the event payload provides a complete audit trail showing what criteria was used for bulk deletion.
…ot set Only include deleteBefore in the payload when it has a value, rather than including deleteBefore: undefined.
Organize the workflow-executed event listener and handler alongside other workflow events for better code organization.
| workflowId: string; | ||
| workflowName: string; | ||
| executionId: string; | ||
| executionMode: 'manual' | 'retry'; |
There was a problem hiding this comment.
Is there really only "manual" and "retry" modes?
Does this event not concern itself with workflows that are executed by a schedule trigger or webhook trigger etc.?
There was a problem hiding this comment.
@konstantintieber I went back and forth on this because we wouldn't have user info for the events that are triggered via other triggers. I chose to just go with the events that were just for the user, as the ticket suggest just needing to know about user triggered events.
Would it be better to have a workflow-executed event with all execution modes, including trigger and error I think - will double-check this, and then have optional user context? WDYT?
There was a problem hiding this comment.
Tricky question indeed.
The audit event name is n8n.audit.user.workflow.executed. From the user, I might infer that this is about manual execution. I guess a non-manual equivalent would be n8n.audit.workflow.executed (following the names we have today)?
The thing is, on the workflow-relay-event-map, the context of the audit event names is missing. So I'm thinking we maybe should use a more specific key there like workflow-executed-manual.
There was a problem hiding this comment.
I've renamed it to workflow-executed-by-user - does that make more sense now?
There was a problem hiding this comment.
Just chucking my opinion in for what it's worth. I'm more a fan of n8n.audit.workflow.executed, and distinguishing the source as being a user (or other), otherwise we may end up with numerous event types just for a workflow execution.
I'd rather have 1 event type, but with multiple filterable fields (source, type, etc) than have multiple event types to wade through.
There was a problem hiding this comment.
@BGZStephen How about I refactor this to go back to the original workflow executed event and add the source? I might just scope this PR to the user-related changes and then add a 2nd PR to do the non-user events. Thoughts?
And should we do the source like:
'user' | 'schedule' | 'webhook' | 'error' | 'trigger'
And then keep the execution mode? 'manual' | 'retry'
Or use a specific source for manual or retry and no execution mode?
E.g. 'user-manual' | 'user-retry' | 'schedule' | 'webhook' | 'error' | 'trigger'
There was a problem hiding this comment.
I like this, user-manual and user-retry make sense to me,
There was a problem hiding this comment.
Sounds good to me too
Make the relay event name more explicit that this event is specifically for user-triggered executions (manual runs and retries), not for all workflow executions like scheduled or webhook-triggered workflows. This addresses PR feedback about clarity in the relay event map.
This comment has been minimized.
This comment has been minimized.
Replace workflow-executed-by-user with a generic workflow-executed event that includes a source field to distinguish execution triggers. This enables future expansion to non-user sources (webhook, trigger, etc.) while keeping the current scope to user-triggered executions. Changes: - Rename event to workflow-executed with optional user field - Add source field with all possible execution sources - Update audit event name to n8n.audit.workflow.executed - Current sources: user-manual, user-retry (others for future use)
This comment has been minimized.
This comment has been minimized.
… event Keep only user-manual and user-retry as active sources for now, with other sources commented out for future PR implementation.
Summary
Adds two new log streaming events for audit logging:
n8n.audit.user.execution.deleted: Emitted when user deletes executionsn8n.audit.user.workflow.executed: Emitted when user manually runs or retries a workflowBoth events include user context for audit tracking.
Related Linear tickets, Github issues, and Community forum posts
https://linear.app/n8n/issue/PAY-2936
Review / Merge checklist
release/backport(if the PR is an urgent fix that needs to be backported)