stroblmeandClaude Opus 5 b0efb4b0f1 Let a node's failure outlive the run that followed it
A node's error cleared the moment it ran again, so a failure that genuinely
fired an alert could leave no trace on the canvas by the time anyone looked.
The engine records it now — on the node's status, so it survives a reload and
every client agrees — and reading the traceback is what clears it. The seam is
the event bus, which is where every failing path already meets: a queued live
run, an explicit run, a preview, and a single triggered node all publish
`node_error`, while the controller's own observer would have seen only one of
them.

That was half the confusion. The other half: clicking a failed neuron on Home
often landed on a flow where everything looked fine. Nodes merge into one
neuron by instance key — every InfluxDB node pointing at the same bucket is one
neuron — and the click went to whichever flow contributed a member first, not
the one that failed. It now goes to the failing member and selects it, and the
canvas marks a failing node rather than leaving it to the dot alone.

The inject node emitted one payload to every port it declared, whatever their
types, so an inject on a bool port carrying the text "true" raised at publish
time. Each port gets its own field now, typed and parsed by that port's dtype,
and remembers what it last sent. A port that is renamed carries its value with
it; one that is removed takes its value with it. An inject written before this
keeps emitting exactly what it did.

The derived-cron chip also appeared on the delay node, where `interval` is a
rate limit and a schedule derived from it means nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Uq8mtNb97A7praJLyeEYgs
2026-08-21 14:33:41 +02:00
2026-02-03 21:43:09 +01:00
up
2026-08-20 10:30:12 +02:00
2026-02-03 21:43:09 +01:00
2026-02-03 21:43:09 +01:00
2026-08-20 22:43:03 +02:00
2026-02-03 21:43:09 +01:00
2026-08-16 00:22:41 +02:00

Fluksio App

Fluksio has the goal to build a revolutionary system to tackle any sort of automation challenge.

The core of Fluksio: a node-based, test-driven automation software built to scale. This repo holds the FastAPI backend, the flow engine, and the dashboard SPA. It is served on app.${DOMAIN} (SPA) and api.${DOMAIN} (API); the marketing site lives in the sibling index repo.

Layout

backend/        FastAPI + SQLModel + Alembic + Postgres
  app/flow/     the flow engine (nodes, pipeline, state backends, controller)
frontend/       React 19 + TanStack Router + Tailwind 4 + shadcn/ui
docker/         compose.yml → compose.dev.yml → compose.local.yml (+ compose.traefik.yml)
scripts/        generate-client.sh, test.sh

Getting started

Normally driven from the workspace root (make init once, then make dev). Standalone:

make install       # uv sync + bun install
make dev-utils     # db, adminer, proxy, mailcatcher, prestart only
make dev-backend   # FastAPI on :8000, hot reload
make dev-frontend  # Vite on :5173
make test           # pytest + Playwright (the e2e half needs the stack up)
make lint           # ruff + mypy + biome
make generate-client  # regenerate the frontend SDK from the OpenAPI schema

make help lists every target.

Documentation

  • ROADMAP.md — strategy and feature record
  • NOTEPAD.md — deferred work and findings
  • DESIGN.md — points at the workspace root's DESIGN-GUIDELINES.md
  • docs/architecture/ in the sibling docs repo — the requirement sources
S
Description
No description provided
Readme AGPL-3.0
7.1 MiB
Languages
Python 54%
TypeScript 42.6%
CSS 1.9%
HTML 0.5%
JavaScript 0.5%
Other 0.3%