A workflow fails. I fix the configuration and click Execute Node.
But what should happen next?
The selected node might depend on three upstream nodes. One succeeded, another produced incomplete data, and the third hasn't run at all.
Should the engine rerun everything? Reuse previous results? Wait for missing inputs?
These questions turn a seemingly simple debugging operation into a problem of dependency analysis, execution-state reconstruction, and data consistency.
While exploring n8n's execution engine, I became interested in how it handles this problem, particularly when partial executions interact with nodes that receive multiple inputs.
Consider an example of a workflow I created
If Generate report fails, restarting the entire workflow might repeat unnecessary API calls or external side effects. Running only that node, however, may fail because its required inputs are unavailable.
The engine must reason about three separate things:
- The Graph topology
- Its Execution history
- Its Execution eligibilty
The workflow's execution state changes with every run.
Partial execution is a state-reconstruction problem
Partial execution allows developers to run a selected portion of a workflow instead of repeating the entire process.
The challenge is deciding which previous results can be reused and which dependencies must be evaluated again.
Data stored in execution history isn't always valid for subsequent runs—upstream parameters can change, and past contexts can drift.
Recomputing everything wastes resources; reusing everything risks incorrect results.
Similar to incremental computation that is recalculating only what changed, workflow engines face extra complexity because nodes trigger external side effects, call APIs, and follow split data paths.
Ultimately, the core problem isn't just deciding which node to run, but determining which execution state is valid to reach that node safely.
Why multi-input nodes complicate scheduling
Here's a node that combines customer data with order data in this workflow
A simplified scheduler might assume that a node is ready when all its parents have executed. Real execution semantics are more complicated.
An upstream node might have executed but returned zero items. Another might not have executed at all. A third might be waiting for data from another branch.
Scheduling cannot always be reduced to checking whether a node's immediate parents have run.
Inside n8n's execution engine
A useful starting point for investigating this behaviour is the WorkflowExecute implementation in n8n's core package:
workflow-execute.ts.
Two areas are particularly interesting.
1) Its Execution Stack
The engine tracks scheduled node work and processes nodes as execution progresses. After a node produces output, the engine must inspect its outgoing connections and determine whether downstream work is ready.
Consider this flowchart
A ["Select runnable node"] --> B["Prepare inputs"]
B --> C["Execute node"]
C --> D["Record output"]
D --> E{"Downstream node ready?"}
E -->|Yes| F["Schedule node"]
E -->|No| G["Wait for required input"]
F --> A
G --> A
This is a conceptual representation, not a complete reproduction of n8n's internal implementation.
The important detail is that producing output and scheduling the next node are separate responsibilities.
2) Reconstructing partial execution
The same file contains runPartialWorkflow2, which provides a concrete entry point for examining partial workflow execution.
At a high level, this path involves resolving a destination, identifying a relevant subgraph, accounting for existing run data, and preparing the execution stack and waiting input state.
The goal is to execute the required portion of the workflow without blindly replaying unrelated operations.
This introduces a correctness requirement: the engine must select the appropriate nodes and supply them with the appropriate data and context.
Exploring the n8n repository and going through its PRs
I explored a few n8n pull requests and came across #10758, titled “fix(core) handle nodes with multiple inputs and partial data correctly during partial executions.”
The PR basically ensures nodes with multiple inputs(like a merge node) handle data correctly during partial workflow execution.
And why is this an interesting engineering problem?
During partial execution, a Merge node might have some upstream data ready while other inputs are still pending. The engine's job is to figure out if it has enough context to safely schedule the node.
While a Merge node shows the problem, the real challenge is with execution scheduling and state reconstruction.
To look into this, I'd check:
- The exact code changes.
- Edge-case test coverage.
- Review the notes on execution-stack reconstruction.
- The PR status (currently marked as a Draft, so it's a proposed idea, not a finished fix).
The main takeaway? Features like partial execution, multi-input nodes, and saved execution data work fine on their own, but keeping their logic intact when they interact is where things will get tricky.
A deeper lesson
This investigation connects workflow automation to several broader concepts:
Incremental computation: Recalculating only the work affected by a change.
Data provenance: Preserving information about where data originated and how it reached a node.
Scheduling: Determining which operations are eligible to execute next.
State consistency: Ensuring that reused execution data remains appropriate for the current run.
Observability: Making enough execution information available to investigate failures and reproduce behaviour.
These concerns are tightly connected. A scheduler can select the correct node but still produce an incorrect result if it supplies stale or incomplete inputs.
A workflow debugger is therefore more than a visual editor. It is also a tool for inspecting and manipulating execution state.
Conclusion
The more I explored partial execution, the less I saw it as a convenience feature and the more I saw it as a test of the execution engine's underlying model.
The challenge is not simply to execute fewer nodes. It is to execute the correct subset of nodes with the correct inputs and the right interpretation of prior state.
Multi-input nodes expose this complexity particularly well because they force the engine to reason about dependencies, data availability, and execution history together.
That is what makes workflow engine development interesting. Correctness often depends on the interactions between features, not just on whether each feature works independently.
Further exploration
n8n Source Repository
Execution engine
Pull request #10758
My Work: REBOOTX
My exploration of automation reliability also connects to REBOOTX — Autonomous Automation Recovery Platform, a project I built to investigate what happens after an automation fails.
Kaashviw3spaces
/
Rebootx-ai
REBOOTX — An open-source AI-powered automation recovery engine that detects failed workflows, diagnoses errors using Gemma, and autonomously executes safe recovery strategies with Temporal.
💜 REBOOTX — Automation Recovery Platform
When automations break, recovery shouldn't be guesswork.
Small businesses and developers depend on automation every day. But when an API fails or a workflow stops working, fixing everything manually can take time.
REBOOTX is an open-source, self-hosted platform that helps detect failures, manage recovery attempts, verify results, and keep a record of what happened.
Instead of blindly retrying everything, REBOOTX combines recovery workflows, safety checks, and outcome verification to make automation failures easier to handle.
⚠️ Current status: Mock recovery is enabled by default. Real n8n recovery is optional and is still partially implemented. REBOOTX does not automatically fix every failure.
✨ What can REBOOTX do?
- 🔎 Detect failures — Receive alerts when an automation fails.
- 🧠 Diagnose problems — Use rule-based checks and AI-assisted diagnosis.
- 🔄 Manage recovery — Coordinate recovery steps using Temporal.
- 🛡️ Apply safety checks — Check permissions and rules…
REBOOTX connects n8n's error path to a FastAPI backend using PostgreSQL, Temporal, and a React dashboard to handle webhooks, validate schemas, track incidents, and coordinate recovery.
It tests AI diagnosis, audit logs, and recovery safety checks, using mock actions.
The key distinction is that detecting a failure, diagnosing its cause, and safely recovering a business process are three different engineering problems.
REBOOTX explores how those responsibilities can be coordinated while keeping recovery actions observable and accountable.
Top comments (1)
partial execution is where the graph idea actually bites.