-
Notifications
You must be signed in to change notification settings - Fork 52.1k
fix(core): Fix for execution history when flow includes wait node #23146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
fix(core): Fix for execution history when flow includes wait node #23146
Conversation
Adds 2 tests to verify timing for executions, waiting and resuming should not impact start time.
|
Found 3 test failures on Blacksmith runners: Failures
|
|
E2E Tests: n8n tests failed after 6m 43.1s Run Details
Failed Spec Files
Groups
This message was posted automatically by
currents.dev | Integration Settings
|
…flow-includes-wait-node
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No issues found across 5 files
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
shortstacked
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks!
|
@tomi Can I get your thoughts on these changes please 🙏 ? Explanation: |
Summary
The workflow execution start time is set via
setRunningfunction, which is fired from multiple places. When the workflow is resumed after waiting, the same function is fired which results with overwrittenconst startedAt = new Date();- causing the bug with wrong execution time.Loom Recording
Related Linear tickets, Github issues, and Community forum posts
https://linear.app/n8n/issue/CAT-1854/execution-history-incorrect-when-flow-includes-wait-node
Review / Merge checklist
release/backport(if the PR is an urgent fix that needs to be backported)