refactor(core): Bifurcate handling of webhooks vs. triggers and pollers (no-changelog) #8494
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
n8n-assistant
bot
added
core
krynble
reviewed
Jan 31, 2024
| @@ -388,7 +389,7 @@ export class ActiveWorkflowRunner { | |||
| responsePromise?: IDeferredPromise<IExecuteResponsePromiseData>, | |||
| donePromise?: IDeferredPromise<IRun | undefined>, | |||
| ): void => { | |||
| this.logger.debug(`Received trigger for workflow "${workflow.name}"`); | |||
| this.logger.warn(`Received trigger for workflow "${workflow.name}"`); | |||
There was a problem hiding this comment.
This change will make the logs quite verbose IMO
There was a problem hiding this comment.
Did this on purpose - this highlighting makes finding relevant logs while testing much easier. They're only temporary, see above:
Switched some logs to warn to make them easier to scan while debugging. Will revert these before merging.
| /** | ||
| * Stop running active triggers and pollers for a workflow. | ||
| */ | ||
| async removeWorkflowTriggersAndPollers(workflowId: string) { |
There was a problem hiding this comment.
Maybe we can deduplicate the remove function above to use this function as well wdyt?
packages/cli/src/commands/start.ts
Outdated
There was a problem hiding this comment.
Looks so much nicer now :D
krynble
approved these changes
Jan 31, 2024
|
✅ All Cypress E2E specs passed |
3 flaky tests on run #3973 ↗︎
Details:
|
|||||||||||||||||||||||||||||||||
| Test | Artifacts | |
|---|---|---|
| NDV > should not retrieve remote options when required params throw errors |
Test Replay
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
|
|
28-debug.cy.ts • 1 flaky test
| Test | Artifacts | |
|---|---|---|
| Debug > should be able to debug executions |
Test Replay
Screenshots
Video
|
|
Review all test suite changes for PR #8494 ↗︎
ivov
deleted the
bifurcate-handling-of-webhooks-vs-triggers-and-pollers-in-multi-main-mode
branch
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.
As our understanding of multi-main setup continues to evolve, this PR again refactors all flows to match what we currently think is the best approach.
leadershipChangeinit.leader-stepdown(former leader realizes they lost leadership), the former leader should remove all triggers and pollers for all workflows and stop pruning. Onleader-takeover(follower became leader), the new leader should add all triggers and pollers for all workflows and start pruning. These events used to beleadershipVacantandleadershipChangewith slightly different effects.Notes:
warnto make them easier to scan while debugging. Will revert these before merging.versionIdto every message when adding webhooks, triggers and pollers increases complexity in the already complexaddandremoveoperations.versionIdis only needed in case we need to deactivate a workflow that failed to activate in the leader in reaction to a message. Is it safe to deactivate on failure without referencing theversionId?