refactor(core): Remove crash recovery from error executions (no-changelog)
#9551
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@krynble to confirm |
n8n-assistant
bot
added
core
krynble
approved these changes
Jun 3, 2024
There was a problem hiding this comment.
Thanks for removing this dead code.
Looking at this code now it does not make sense, but at the time we still had own mode, which ran in a separate process.
In case of a failure on the child process, it would simply exit and would invoke the call to processError which could then restore the execution if it failed.
This does not make sense anymore since own mode was removed, so all executions reaching this point should be due to an actual execution error, as crashes are now handled elsewhere.
|
✅ No visual regressions found. |
2 flaky tests on run #5276 ↗︎
Details:
|
|||||||||||||||||||||||||||
| Test | Artifacts | |
|---|---|---|
| NDV > should not retrieve remote options when required params throw errors |
Screenshots
Video
|
|
24-ndv-paired-item.cy.ts • 1 flaky test
| Test | Artifacts | |
|---|---|---|
| NDV > resolves expression with default item when input node is not parent, while still pairing items |
Test Replay
Screenshots
Video
|
|
Review all test suite changes for PR #9551 ↗︎
|
✅ All Cypress E2E specs passed |
|
Got released with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Crash recovery amends an execution using event logs and then runs post-execution hooks. This recovery is only intended for an execution truncated by an instance crash, is only performed by a main process (i.e. no crash recovery for production executions in queue mode), and is being triggered...
EventBusduring server startup, andWorkflowRunner.processError, which is called from two catch clauses inWorkflowRunner.runMainProcess(main mode) and from three catch clauses inWorkflowRunner.enqueueExecution(queue mode).If an execution has reached
WorkflowRunner.processError, then we know the execution has failed, i.e. it finished with anerrorstatus, rather than being truncated by an instance crash. A failed execution already has the data that is populated by the crash recovery mechanism:executionData.resultData.runData,executionData.resultData.error,status, andstoppedAt.Hence there should be no use in crash recovery for
errorexecutions.Follow-up to: #9512