DEV Community: Kaashvi

A Workflow Is a Graph. An Execution Is a State Problem: The Hidden Complexity of n8n.

Kaashvi — Tue, 27 Oct 2026 00:55:11 +0000

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…

View on GitHub

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.

Explore REBOOTX on GitHub

This is How I Automated My Digital Chores To Get More Hours Of Sleep (Python + Ollama)

Kaashvi — Mon, 26 Oct 2026 09:17:44 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Idler is a local-first AI assistant that helps people do everyday computer housekeeping tasks using plain English instead of complicated commands or endless clicking.

One desktop. 143 files. Where do we even start?

The idea is simple: tell IDLER what needs doing, review its plan, and decide whether it should go ahead.

But there's an important design decision here.

I don't want an AI model to have unrestricted access to someone's computer. A model can misunderstand a request, suggest an incorrect action, or produce an output that looks convincing but isn't safe to execute.

So Idler follows a more controlled approach: the AI proposes a plan, deterministic checks validate it, the user approves the proposed changes, and restricted tools carry out the permitted operations.

The goal isn't to make AI magically trustworthy. It's to build a system where the AI can be useful without being given unlimited power.

For example, instead of manually going through a folder containing hundreds of files, you could ask:

"Help me organise these files into sensible folders."

Or:

"Find duplicate files in this directory so I can review them."

Some of the housekeeping tasks I'm building around include:

File organisation: Make cluttered folders easier to navigate.
Duplicate detection: Identify repeated files and help users review them.
Spreadsheet housekeeping: Inspect CSV files and surface useful information, including potential data-quality issues.
Project housekeeping: Help inspect project folders and identify things that may need attention.
Action history and undo: Keep track of supported operations and provide a way to reverse eligible changes.

Demo

Download Latest Release (v0.2.4)
Watch the Video Demo on YouTube

Code

Kaashviw3spaces / Idler

Idler takes care of the computer chores you’d rather not do — tidying folders, finding duplicate files, checking messy spreadsheets, and keeping things in order. It gets stuff done, with you in control.

🦥 Idler

Your computer is a mess. Your sloth has a broom.

A digital housekeeper for all the computer chores you've been avoiding.
Less mess. Less busywork. More time for absolutely anything else.

🧹 File housekeeping · 🔎 Duplicate hunting · 📊 Spreadsheet checks

So... your downloads folder looks like this?

Downloads/
├── final.pdf
├── final_FINAL.pdf
├── final_FINAL_v2.pdf
├── final_FINAL_v2_ACTUAL_FINAL.pdf
├── new_folder/
├── new_folder_2/
├── new_folder_2_REAL/
├── random_screenshot_8472.png
└── spreadsheet_use_this_please.csv

You needed one file.

You now have a small archaeological site.

And somewhere in that mess is the document you actually need, three copies of a spreadsheet, and a screenshot you took six months ago for reasons nobody remembers.

We've all been there.

Idler is here to help with the little digital messes that somehow become tomorrow's problem.

It's an AI-powered computer housekeeping assistant that takes instructions in plain English, prepares a plan, and helps carry out supported tasks with…

View on GitHub

How I Built It

Idler is built on a decoupled, resilient architecture consisting of an Electron native shell, a high-performance React 18 UI, a standalone compiled FastAPI engine, and an atomic SQLite ledger.

Every move was guarded: previewed first, logged before modification, verified on disk, and instantly reversible.

Because Squirrel.Mac requires paid Apple Developer certificates ($99/yr) to apply updates, we engineered a native, zero-dependency updater for macOS and Windows that requires zero external services.

Tech Stack

The Automated Testing & Rigorous Verification

My Hacktober Timeline

Why Does Open Innovation Matter?

Open innovation matters because it encourages collaboration, knowledge-sharing, and the exchange of ideas beyond organisational boundaries. It reduces development costs, accelerates problem-solving, and makes technology more accessible. By combining diverse perspectives and expertise, it helps create better solutions and drives continuous improvement.

The Lazy Payoff

My computer has 143 files on its desktop. At some point, “I’ll organise these later” became a long-term storage strategy.

Idler was my attempt to break that cycle.

Instead of manually dragging files into folders, hunting for duplicate downloads, or opening spreadsheets just to figure out what’s wrong with them, I can ask for help in plain English. Idler plans the task, lets me review the proposed changes, and only executes actions I approve.

The real payoff? Less clicking, less repetitive housekeeping, and fewer reasons to procrastinate.

Is it a scientifically verified productivity revolution? Not yet. Is it an attempt to make my computer slightly less embarrassing? Absolutely.

My desktop still has problems. At least now, my sloth has a broom.

Prize Categories

Best Use of Gemma — For Idler's open-weight AI approach, using Gemma through local inference to help interpret user requests and plan computer housekeeping tasks.

Best Use of GitHub Copilot — If GitHub Copilot was meaningfully used to build or improve Idler, in accordance with the category requirements.

Team Member

@saksham_malik_2606

One Broken API Can Disrupt a Business. So I Built Something to Help.

Kaashvi — Mon, 19 Oct 2026 00:08:54 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Imagine running a small business where your inventory updates automatically, customer notifications go out through workflows, and different tools stay in sync without you having to do everything manually.

Now imagine one API fails.

An order doesn't get processed. Inventory stops updating. A customer never receives their notification. And suddenly, you're spending time digging through logs instead of running your business.

For a small business, even a minor automation failure can turn into a frustrating operational problem.

That got me thinking: what if there were a system that could detect these failures, figure out what went wrong, and safely handle recovery whenever possible?

That's the idea behind REBOOTX.

I built it as an open-source, self-hosted automation recovery engine that currently integrates with n8n. I focused on getting the components to work together, testing the recovery flows, and making the system easier to run locally.

Demo

📥 GitHub Release: Install REBOOTX
🎥 Video Demo: See it in action

Code

sakshammalik260-cse / 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…

View on GitHub

How I Built It

Here's the high-level architecture:

n8n → FastAPI → PostgreSQL + Transactional Outbox → Temporal → Recovery Worker→ Verification → Dashboard

Each component handles a different part of the incident lifecycle.

Separating these responsibilities makes the system easier to reason about and gives each component a clear job.

The Tech Stack Used

End-to-end incident lifecycle

For failure to recovery, in 8 steps:

Security, safety, and tenancy

Tenant authentication: Read tokens are securely hashed before storage in PostgreSQL.
Webhook security: HMAC-SHA256 protects incoming events; secrets stay in environment variables.
Data isolation: Tenant-scoped operations and idempotency controls protect data and prevent duplicate processing.
Safe defaults: Mock recovery and mock AI are enabled by default.
Controlled changes: Real n8n workflow changes require explicit authorisation and fingerprint matching.
Credential protection: .env files and runtime credentials are excluded from version control.
Known limitation: Temporal’s internal-network TLS exception needs hardening before exposure to untrusted networks.

What has actually been built and verified?

The checkpoints:

Simulation, test and verification report | v0.1.0 | 18 October 2026:

These results gave me confidence that the core incident-to-resolution pipeline was working in the tested environment.

There is an important limitation, though: one recovered incident out of two simulated scenarios is not a meaningful estimate of real-world recovery performance. We deliberately selected the scenarios to test different paths.

The project still needs broader load testing, failure-infrastructure testing, independent security review, and clean-install verification on another machine before I can make stronger claims about production readiness.

I would rather be clear about those limitations than claim that a successful test suite proves everything is ready for production.

[Insert Image 4: A screenshot of your actual terminal showing the backend and frontend test results, with any secrets or personal paths hidden.]

Why Does Open Innovation Matter?

Small businesses should not need expensive enterprise software to manage automation failures.
Open innovation makes my approach possible. Developers can inspect the code, contribute improvements, extend integrations, and adapt the system to different business needs instead of depending on a single proprietary solution. Docker Compose also makes self-hosted deployment more accessible.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle
Best Use of Temporal — REBOOTX uses Temporal to orchestrate durable recovery workflows, track execution, and coordinate incident recovery.
Best Use of Gemma — REBOOTX includes a Gemma diagnosis-provider integration path for AI-assisted failure analysis. The default configuration uses a mock provider.

Team Members

@saksham_malik_2606 for ideating and building it.

Outside or else! Here's how we made AI pets bribe and threaten users to go Touch Grass

Kaashvi — Sun, 11 Oct 2026 21:44:29 +0000

Ugh man i just always feel like doomscrolling to relax my mind, I wish someone would look me dead in the eyes and say 'go outside or else' while slowly loading a paintball gun.

-a known friend

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Most wellness and habit-tracking apps fail for a simple reason: they act like boring productivity managers. They send polite notifications that everyone swipes away after two days.

My friend Prachi stays inside working at her desk for several hours a day. She loves cozy aesthetics, and silly internet pet humor. I wanted to build something for her that makes going outside feel like a cute mini-game backed by a pet that speaks in unhinged broken cat logic and escalates to chaotic demands if you try to ignore it.

That is Outside or else!: a cozy, ambient PWA built with open-weight local AI, OpenStreetMap data, and Google Font Gaego.

The entire app is built on a simple idea: screen time should be the shortest part of the experience. You pick an outdoor goal, and your pet guides you outside, locks your app during your walk, verifies your outdoor selfie locally on your phone, and remembers your journeys in a scrapbook. But if you ignore it twice? The pet dies of extreme sadness. You pet's love for you increase with every selfie you add to its memory book, once it dies you lose the bond and the memories.

Demo

📥 Download APK: Get the latest Android release
🎥 Video Demo: Watch the app in action

Code

sakshammalik260-cse / Outside-or-Else-

Outside or else!

Your pet has one mission. Get you outside.

A mobile-first React + TypeScript cozy outdoor companion game built around on-device local AI models, privacy-first offline persistence, and open map data.

🌟 Overview

Outside or Else! turns stepping outside into a tiny adventure. Adopt a pet, nurture a bond, and receive chaotic, unhinged reminders to step away from your screen. Screen time should be the shortest part of the game.

OUTSIDE OR ELSE! PWA

FRONTEND & UI
│ • React + Vite + TypeScript
│ • Hand-drawn Gaegu Font
│ • SunCalc (Ambient Lighting)
│ • OpenStreetMap / Overpass API

NATIVE ANDROID (CAPACITOR)
│ • llama.cpp (Qwen3-0.6B GGUF AI)
│ • Native Camera & Local Photos
│ • Local Notification Engine
│ • On-Device File Persistence.

✨ Features Included

7-Step Onboarding & Pet Selection: Short skippable splash screen guiding users through companion choice, naming, activity preferences, outdoor time…

View on GitHub

How I Built It

Outside or Else! is built around on-device local AI models and open map data to ensure zero tracking and 100% offline functionality:

Local On-Device AI Generation (Qwen3-0.6B + llama.cpp):

The Android app bundles a quantized Qwen3-0.6B open-weight model and runs it locally using native llama.cpp integration. The pet generates new replies offline in airplane mode with zero cloud chat APIs or external downloads.

Ask Cat a question or trigger a response?

Cat generates replies locally: "human. you have legs. why are they not moving? MEOW HEEK!"

Grounded Suggestions & Real Walks (OpenStreetMap Overpass API + SunCalc):

Using SunCalc for dynamic room lighting and local OpenStreetMap queries via Overpass API, Cat calculates nearby walkable parks and sky timing, generating grounded suggestions in its unhinged voice:

"sky orange at 5:42. like big salmon. go to park now."

It even suggests users to try out a new place or landmark scanned by the model within the users proximity.

UI & Styling:

Typography: Set to Google Font Gaegu with bold, oversized headers (text-4xl) and subheaders (text-2xl).

Visuals: Warm pastel ambient lighting, soft borders, and an integrated bottom navigation bar (Nest, Outside, Brain Folder, Knobs).

Tech Stack

React • TypeScript • Vite • Capacitor • Android • Qwen3-0.6B • GGUF • llama.cpp • OpenStreetMap • SunCalc • Gaegu

Why Does Open Innovation Matter?

Open-weight AI puts a real model inside your phone. Here is why closed APIs couldn't do this:

Works 100% Offline: Closed APIs need internet. Bundling llama.cpp and Qwen3-0.6B lets your pet chat in airplane mode or on a trail.

Total Privacy: Closed APIs send your data to cloud servers. Open-weight AI keeps your pet chats, photos, and walks strictly on your device.

Zero API Costs: Closed APIs charge per request. Open-weight AI and OpenStreetMap run completely free forever without server bills.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass
Best Use of Open-Source AI: Built with a bundled, quantized Qwen3-0.6B model running 100% locally on-device via llama.cpp—zero cloud dependencies, zero external APIs, and full offline support in airplane mode.
Best Use of Gemma: Tested with a quantized Gemma GGUF model on llama.cpp
Best Use of GitHub Copilot: Assisted in writing React, TypeScript, llama.cpp native Android integration code

What I Learned & Final Thoughts

A cute concept is easy to pitch, but making an offline AI model run on real Android hardware, preserving local state during upgrades, and handling native permissions takes real engineering.

Most apps want you to stay. Outside or Else! wants you to leave. Take a short walk, watch the sky, bring back a photo, and let your pet greet you with an unreasonable demand:

😼 "HUMAN. DOOR EXISTS. LEGS EXIST. GO TOUCH GRASS. HEEK!"

Team Members

Built with @saksham_malik_2606 (consistently advocates touching grass)