-
Notifications
You must be signed in to change notification settings - Fork 7.1k
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
fix(core): Adjust starter node priority for manual executions with pinned activators #8305
fix(core): Adjust starter node priority for manual executions with pinned activators #8305
Conversation
|
||
// partial manual execution | ||
|
||
const [firstStartNodeName] = startNodeNames; |
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.
This preserves existing behavior - if the partial manual execution has 2+ start nodes, we search only the zeroth start node's parents for a pinned activator. If we had 2+ start nodes without a common ancestor and so if we end up finding multiple pinned activators, we'd still need to return one to comply with existing usage, so I assume that picking the zeroth starter node here is correct, even though arbitrary.
|
|
3 similar comments
|
|
|
Closing in favor of #8386 |
Story: https://linear.app/n8n/issue/PAY-1099
This PR adjusts starter node priority for manual executions with pinned activators, prioritizing
n8n-nodes-base.webhook
over other activators. Also, this PR consolidates the search for starter nodes for manual executions and subworkflow executions.Out of scope - these legacy methods are also due for consolidation:
WorkflowHelpers.getExecutionStartNode()
Workflow.getStartNode()
Workflow.__getStartNode()