21 Commits

Include renames

Author	SHA1	Message	Date
stroblmeandClaude Opus 5	9a5371d4c7	Keep a failed node's traceback on the run ... The worker already sent it and the log panel already got it; the failure outcome kept the one-line error and the node's stdout and dropped the rest, so reading a failure back meant reproducing it under `run --local`. It rides in the node's logs now — no schema change, and the API row, the run detail page and `RunHandle.failures` carry it as they are. `_record_node` keeps the tail of the log cap rather than the head, so a chatty node cannot push the traceback past it, and `fluksio run` prints what each node said when a run does not end ok. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TXQv6KNyyvY7Z1etYTUUAd	2026-08-31 07:52:24 +02:00
stroblmeandClaude Opus 5	989d008d37	Merge branch 'main' of git.stroblme.de:Fluksio/app ... The two sides both touched `submit_ready`'s readiness check, for unrelated reasons, so the conflict is textual rather than semantic and both changes stand: - `831a537` completes a node that is not ready instead of passing over it, so a producer that can never run stops stranding its consumers. - the audit branch has `_is_node_ready` return the values it read, so the node runs on them instead of asking state for the same keys again. Merged as: read once, keep the values whether or not the answer is yes, and take the not-ready branch from `831a537`. Its reasoning holds under the merge — by the time readiness is consulted, `in_degree` is zero and every in-wave producer has finished, so the answer cannot change later in the wave. Also fixes a fixture this branch added: the module-scoped row cleanup in `tests/conftest.py` assumed a schema, and `tests/flow` overrides `db` with a no-op because those tests need no database. It only showed when that directory ran on its own. 746 tests green, and each directory green alone. Engine throughput is unchanged by the merge (559 msg/s on the memory backend, against 639 before it and 262 at the start of the audit). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M6hPWS6YEbT1P8LxhhFb2T	2026-08-29 21:22:12 +02:00
stroblmeandClaude Opus 5	1069247085	Coalesce the event bus, and fix the socket that ended on a client frame ... A three-node cascade publishes 13-16 events and each one crossed to the event loop on its own. They are one `call_soon_threadsafe` now — whatever was published between two turns of the loop goes over together — and every subscriber still receives every event, oldest still dropped first when one falls behind. The socket end of the same path: - **any frame from the client ended its stream.** `receive_text` was awaited once, outside the loop, so a keepalive — or anything else a client decided to say — satisfied it and was read as the client going away. It is recreated per iteration; only a disconnect ends the stream. - events go out in one frame per wave (`{"type": "batch", "events": [...]}`, capped at 64), serialised once with orjson rather than per client with the stdlib's `json.dumps` through `send_json`. The client unpacks a batch and still understands single frames, so an older engine behind a newer bundle keeps working. - authenticating and building the snapshot happen on a thread. Both were on the event loop: one is a database round trip, the other reads the whole of state, per connect and again per `dashboard_changed` per panel. `Pipeline.values()` — what that snapshot is — no longer SCANs the whole Redis namespace. It scanned five bookkeeping keys for every message to find the messages; `RedisState` keeps a set of the names beside them and answers from it. Maintained wherever a message is written, so a seeded value or a deleted flow keeps it exact. On the client, while in the same file: - a `node_health` event invalidates the flow's detail. The canvas draws health from the server-derived `issues`, so a node going down or recovering only showed on mount, navigation or a rebuild. The store had a health map of its own that nothing ever read; it and `useNodeHealth` are gone rather than wired up, since the server's view is the one the canvas already uses. - a reconnect invalidates the five key families this socket feeds instead of the entire cache, and the backoff is jittered. The usual reason a socket dropped is the engine restarting, so every tab and every wall panel refetched everything, together, at the moment it was least able to answer. - a frame that will not parse costs the frame, not the connection. It was the one unguarded `JSON.parse` in the app; an exception there escaped to `window.onerror` and left whatever it had already applied behind. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M6hPWS6YEbT1P8LxhhFb2T	2026-08-29 20:08:50 +02:00
stroblmeandClaude Opus 5	da528340a9	Cut the round trips a message costs the engine ... Measured with `make bench-engine` against a real Redis: 103.6 -> 164.4 messages a second on a five-node chain (p50 latency 2125 -> 1171 ms) and 34.8 -> 63.2 on a fan-out of twenty. Against the memory backend, which is what a pip install runs on, 262 -> 626. The two that bought most of it: - `StateBackend.record` puts a published value, its timestamp, its series and its version counter in one round trip. They were four calls building four pipelines, and a value crossing an edge pays them twice. A released rate-limit hold rides along instead of a DEL per port. - the readiness check reads a node's inputs and hands them to the node, rather than reading the triggering ones to count them and having the node read the same keys again a moment later. `apply_outputs` was a second copy of `_record_outputs` and is now the same code plus the event that distinguishes it. The rest, each small: - `_derive` builds a node-by-id map and a `consumes` index, so dispatching an item and publishing a value stop scanning every node in the installation. - `read_all` is memoised against the store revision — it sits on the publish path, so a dashboard slider was reading and validating every flow file per value. Same mechanism `_wiring` already uses. - the `message_value` source block is built once per node instead of per emission. - both timer threads ask the queue to promote only when something is actually due, which takes an idle engine from ~4 Redis round trips a second to one. - the shared httpx client is bounded (32 connections, one retry); its default pool is 100 with no per-host cap, so one slow endpoint could take it and every other sender node with it. - the MQTT and delay nodes no longer log a line per message at INFO. Robustness, in the same pass: - `MemoryWorkQueue._done` was a set nothing ever removed from — one entry per non-idempotent node per item, for the life of the process, in the default configuration. Capped, the way the Redis side expires its markers. - a saturated engine can claim from the due lane past the cascade limit. The capacity gate sits in front of the claim, so the due lane's priority — decided inside it — did not apply while every slot was held: a motor's stop was not behind the long nodes, it was unread. Only after a slot has genuinely failed to free for half a second, and briefly, so the backlog is not starved in turn. - `reclaim_stale` dispatches through that same gate. It could return sixty entries and push in-flight far past the limit the gate exists to hold. - a flow's nodes are stopped together rather than one after another. Each gets `NODE_STOP_TIMEOUT`, so a flow whose broker was unreachable took five seconds per node — long enough to outlast `REBUILD_WAIT` and 503 the deploy. - the worker pool and the HTTP client are closed on a thread, not on the event loop, and a run closes the state backend it built (on Redis, a client and a connection pool per run). - the five background tasks say something when they die. Each catches exceptions inside its loop, so one raised anywhere else left the engine serving with no metrics, no alerts or no artifact sweep, silently. `tests/flow/test_round_trips.py` counts the state operations one message costs — four, where it was about eleven — because none of the above would fail a behavioural test if it were undone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M6hPWS6YEbT1P8LxhhFb2T	2026-08-29 19:58:39 +02:00
stroblmeandClaude Opus 5	b4e6a0df11	Merge branch 'main' of git.stroblme.de:Fluksio/app ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5H4uLCCpsbipL1R7WKCee	2026-08-29 16:42:07 +02:00
stroblmeandClaude Opus 5	831a537980	Stop a quiet producer vetoing a noisy one in the same wave ... Both boilers on the house had been unable to switch on since the Node-RED transition, and the reason was here rather than in their logic: the command reached `boiler.water_boiler` and stopped, because `dmx.switches` never ran. A wave orders nodes by a dependency count, and two things decremented that count only on success: - a node that published nothing — rate limited, unchanged, or failed — never freed its consumers. `dmx.switches` reads both boilers through `rbe` nodes, so the kitchen one being unchanged, which it is nearly always, held the main one's command back. The encoder ran about four times an hour, and only when the lights happened to change in the same wave. - a node that could not run at all never freed them either, permanently. `plugs.pump_run` waits on a watering pulse that only exists at 02:00, so every wave it appeared in took its consumers out with it. Freeing a consumer is not the same as running it: `untouched` already refuses to run anything whose inputs nothing refreshed, and that is the accurate test. The dependency count is ordering, not permission. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5H4uLCCpsbipL1R7WKCee	2026-08-28 16:53:49 +02:00
stroblmeandClaude Opus 5	70e542ec3c	Surface a failing connector poll as node health and a flow issue ... The poll loop remembered what it read rather than what it published, so a value the node could not publish counted as said: the next poll skipped it, succeeded, and health went back to ok with the port still dark. Remember it only after inject returns, and report ok last. A node reporting itself down is now derived into its flow's issues on read and counted on the health summary, so the canvas marks it and Home says so. Being down does not stop the flow, and the issue clears by itself when the node reports well again. The repeating poll warning is logged once per outage rather than once per tick. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K1moruzue2kTJd3uVisgNk	2026-08-28 12:22:55 +02:00
stroblmeandClaude Opus 5	37a7df9d24	Let a sweep run more than four at a time, and name the run a failure was in ... Concurrent runs sat at 4 whatever FLOW_MAX_CASCADES said: that setting bounds cascades, and the run drivers read a hardcoded MAX_PARALLEL nobody could reach. FLOW_MAX_RUNS is the knob they read now, --max-runs/--max-cascades/--max-workers are the same three as flags on serve, and the engine says which numbers it started with — which is the only way to tell that a settings file was read. Events keep the run they happened in. The payload always carried it and the persist path dropped it, so reading one run's failures meant filtering the engine-wide list; a batch run's id reaches those events now too, since a run has no journaled item to name itself by. Also: a provisioner's 0 means "no deadline" rather than "cancel on the next reconcile", and a command that reaches no engine says how to start one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015sbYeYaVgYQqm1sbx7wPdL	2026-08-27 14:17:51 +02:00
stroblmeandClaude Opus 5	c3675688c8	Wait for a deadline instead of polling for one ... The timer thread promoted due work on a fixed one-second tick, so every delayed item was 0-1000ms late whatever the load — measured on the house at 705ms mean on a rollershutter stop, which is 2-4% of a 26-second travel and accumulates in the position the motor node believes it is at. It now sleeps to the soonest deadline and is woken when a nearer one is scheduled, which measures 0.9ms end to end through Redis. A promoted timer also went to the back of the queue. It goes into a due lane of its own that `claim` reads first, so work that has waited out a deadline is not held up by work that is merely queued. Beside it, in the same code: seeding a message now bumps its version, so a re-put flow's synchronous nodes no longer wait forever on a value that is sitting in state; the consumer group drops the consumers of engines that are gone (138 had accumulated on this installation); and the cast that closes the long-standing `xclaim` mypy error. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-27 11:51:58 +02:00
stroblmeandClaude Opus 5	0ffcabfdb9	Media dtypes: image, audio and video as narrowed artifact references ... A port may now declare `image`, `audio` or `video`. Each is the artifact reference the engine already had, narrowed by the `media_type` on it, so a speech recogniser declares what it eats rather than taking any bytes at all and finding out. Bytes still never travel as a message and nothing on the wire stops being JSON: a camera publishes one reference per frame, a microphone one per chunk, and a reference may carry a `meta` dict nothing here interprets. Streaming media is therefore an ordinary streaming port — with one change to what that means. An emission used to journal an item with no payload, so downstream read whatever was current when the item was claimed; a consumer slower than its producer saw only the newest chunk and the ones between were lost. That is right for a training curve and wrong for a second of speech, so an emission now journals a `kind="emission"` item carrying its values, and the executor hands them to the nodes reading that message instead of writing them to state again. The value in state stays the latest, which is what everything else reads, and the wave is filtered by what actually changed rather than walking everything reachable. No queue serialization change — the existing `outputs` field carries it. Continuous media makes the store's missing GC a real problem, so this closes it: `sweep_artifacts` runs hourly, keeps every digest a `run_artifact` row records or a live message holds, spares anything written in the last hour, and stands aside entirely while a run is in flight, since a node may store a checkpoint long before it returns the reference to it. That also collects the orphans a deleted flow has always left behind. `ARTIFACT_GC_INTERVAL_S=0` turns it off. Around the edges: `GET /artifacts/{digest}` serves the media type the caller passes and answers ranged requests, so a browser plays a clip rather than downloading it; `PUT` spools to disk instead of holding the whole body in memory, as does `save_artifact` given a path; a Media widget draws whatever its message points at, and a wall panel may fetch the bytes its own tiles are showing and nothing else; and a connector gets `save_artifact`, for a device whose readings are bytes. What this cannot do is live video: a frame every second or two is a glance, and the honest answer above that is the camera's own stream, which the widget takes as a URL and the browser plays from source. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-26 23:44:55 +02:00
stroblmeandClaude Opus 5	4f3eaf950c	Report a published node that has no code of its own ... The store answers the new-node template when nothing was ever written for a node, so such a node ran — returning {} on every call, reporting active and ok, and saying nothing anywhere. Unreachable through `fluksio sync`, which writes every body before it publishes; the editor end was open. A run of a flow holding one is now refused, and the flow carries a missing_source issue so it is visible before anybody runs it. A draft is exempt: a node being written legitimately has no published body yet. The generated client is regenerated for the new issue code, which also catches up the drift left by earlier backend work (resources, code_digest, idempotency_key). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-26 22:55:11 +02:00
stroblmeandClaude Opus 5	001ec7b282	Key the stage cache by the node's input names, not the flow's ... A cache key held qualified input names, so the same node reading the same values through two flows keyed differently and only a node with no inputs could ever hit across one. The fingerprint beside the key already says what the node is, and it has been flow-agnostic since it moved ahead of assign_flow — the names were the last thing tying an entry to one flow. Inputs now reduce by the node's own name for them; a name belonging to another flow keeps its prefix, since reading it is part of what the execution is. Every stored entry misses once and is re-run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-26 22:41:35 +02:00
stroblmeandClaude Opus 5	180da3d640	Stop paying five Redis round trips and a global lock per message ... The engine was I/O-bound on its own state backend. `RedisState.lock()` is one key — `pipeline:_lock` — for the whole process, taken five times a message at two round trips each, and every cascade and every node read queued behind it. Inside it, reading a node's inputs was three round trips per input (an EXISTS for `in`, then EXISTS and GET for the value), writing was two updates that a single transaction already gives, and the version counters went one INCR at a time. Replaced with the atomic command that was always available: `get_present` is one MGET and tells a missing key from one holding null, so the lock it used to be read under bought nothing; value and timestamp land in one `update`, which is a MULTI/EXEC; `increment_multi` pipelines the counters. `values()` — what every websocket snapshot calls — is two reads whatever the message count instead of two per message. Beside that: every webhook did its blocking XADD on the asyncio event loop (MQTT already used `to_thread`); the per-execution `NodeOutcome` was built and validated even with no run watching; `_minute` built a tz-aware datetime per event on the loop thread to key a dict, and now keys on an int; `move_due` promoted delayed items one round trip each, every second; `FLOW_MAX_CASCADES` makes the in-flight ceiling a setting rather than a constant. `orjson` replaces stdlib json where a message pays for it — state, the journal, the engine side of the worker pipe. `fluksio-worker` stays dependency-free, and the run-cache digest stays on stdlib so no stored key is invalidated. A non-finite number now stores as `null` rather than the bare `NaN` that was never JSON. Measured with `scripts/bench_engine.py` against a real Redis, 200 messages: a five-node chain went from 43.9 to 103.1 msg/s with p50 latency 2110ms → 782ms and p95 3913ms → 1439ms; one source into twenty consumers went from 5.4 to 33.7 msg/s. In memory, twenty consumers went from 187 to 448 msg/s. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BpfSinyCBfjuieikyfMPbf	2026-08-26 10:12:25 +02:00
stroblmeandClaude Opus 5	a9136c7811	A rate limit now thins the work, not only the messages ... The limit was applied in `apply_outputs`, which the executor reaches after the item is off the queue — so a subscriber told to publish every 15s still cost a queue entry, a `cascade_started`, a run record and a walk of everything reachable from it per inbound message. Seven relay nodes behind one inverter ran 192 times a minute to publish six. Two halves, matching the two shapes it takes: `trigger()` now keeps a value whose every port is inside its window and journals nothing at all. The window split came out of `_throttled` as a read-only `_window_split`, so the question is asked the same way in both places and the exact split is still made once, at claim time. A cascade carries the names it actually published, and the wave runs only the nodes something in that set feeds. A node whose triggering inputs were all held back is completed without running, which frees its own consumers to be judged the same way — the case where a node re-published 619 messages a minute off inputs that changed six times. Redeliveries and emissions carry no such set and still walk everything, since one has a half-finished wave to finish and the other is the value already being in state. Skipping a node can make one ready that the scheduling pass has already walked past, so `submit_ready` runs to a fixpoint. That also closes the same latent hole on the replay path, where a done-marker skip could strand a join with no future outstanding to come back for it. Measured with the new `scripts/bench_engine.py`, 500 messages through the house's shape: a limited source went from 500 cascades / 3500 node runs / 5009 events to 1 / 7 / 19, publishing the same 8 values; an unlimited source into limited relays took the node reading them from 500 runs to 1. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BpfSinyCBfjuieikyfMPbf	2026-08-26 09:55:56 +02:00
stroblmeandClaude Opus 5	3af5342a2b	Advisory issues read as advice rather than failure ... `ADVISORY_ISSUES` moves next to `ValidationIssue` in pipeline.py, and the model derives an `advisory` flag from its own code, so the distinction the engine already made ships to the client instead of being re-guessed there. The dock keeps its summary in `--destructive` only when a real fault is among the issues and paints an advisory row `--muted-foreground`; the canvas leaves advisories off a node's dot and border entirely, since node status has three colours and no warning tier. biome checks the generated `openapi.json`, which nothing formats since the SDK script dropped its format pass — ignore it like the other generated files. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013Gf7WaExcJ9bs3kfJXB3nK	2026-08-25 21:46:40 +02:00
stroblmeandClaude Opus 5	a3a234756c	A batch flow's input is a run parameter, not a missing value ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UytviPMJbXzD8P84nLvXcq	2026-08-25 18:51:54 +02:00
stroblmeandClaude Opus 5	3c15964364	A cached node keeps its curve, and any input can name a run's output ... A cache hit still replays no emissions — those values were the story of an execution that is not happening — but the run they were recorded in is now written on the row (`run_node.cached_from`), and the metrics endpoints read the series back from there. So a reused run answers `run.metrics("train.loss")` with the same points the run that trained did, rather than looking like a run that produced no numbers at all. Pointed at rather than copied: a sweep of 500 reusing one frozen node would otherwise duplicate its curve 500 times. That needed the cross-flow restore fixed first. The cache key has no flow in it while the stored outputs are named for the flow that produced them, so `quick.prepare` getting a hit from `train` wrote `train.dataset` into `quick`'s state and the next node was called without its argument. One rule now covers both halves: `requalify` reads a name owned by one flow as the same name in another, applied to the restored outputs, to the node id behind the pointer, and to the series names on the way out. Reuse across flows is kept. Also: `@run:<id>.<output>` and a bare `sha256:` digest resolve on every input, not only artifacts. Chaining a run's json config into the next one from a shell meant pasting the whole object inline, and the CLI could not even send the spelling — `_coerce` died in `json.loads` before the engine saw it. Both spellings are reserved on every input now, `str` included, and `_from_run` returns whatever the run's result holds rather than only a reference. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Dp9L6gakMVro1K2C5zdtBE	2026-08-25 15:12:28 +02:00
stroblmeandClaude Opus 5	400d7d9c5c	Stage caching for batch runs, and an engine that lives in the command ... A code node in a batch run is now fingerprinted by its source, its raw settings and the values it reads — an artifact input counting as its digest, which is what the content addressing was always for. A run that finds the key restores what the earlier one returned and skips the node, recorded as `cached`. The run history is the cache: `run_node.outputs` beside the `cache_key` the schema already had, no second store. On for code nodes, never for the built-in and connector types that have side effects; off per node with `@node(cache=False)` and per run with `--no-cache`. Emissions are not replayed on a hit, so a cached training node returns its result without redrawing its curve. Recorded in NOTEPAD.md with the two other deliberate limits. `fluksio run --local` boots the real app in the command's own process and drives it through its ASGI interface behind the ordinary client, so a run no longer needs a `serve` terminal beside it — same data directory, same history, and the cache carries between the two. It always waits, because the engine it starts lives exactly as long as the command. Also: `fluksio sweep --param lr=0.1,0.01` for the product of the lists, `run --follow` for a run's numbers as they arrive, Ctrl-C cancelling a waited run rather than abandoning it, coloured statuses on a terminal, and `name` made optional on the metrics endpoint so a follower can ask for every series. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-24 20:31:31 +02:00
stroblmeandClaude Opus 5	32bc0a5e66	Say a rebuild has two scopes, and close the notepad items it fixes ... The module docstrings and the notepad still described one rebuild that touches everything. Closes the toggle cost, the seeding cost, the per-save rebuild, the modules/apply rebuild and the Playwright spec that could not fit a rebuild into its five seconds; files the follow-ups the refactor leaves behind. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01StpRc2C6au1WJ1EUU7fsfu	2026-08-23 19:05:23 +02:00
stroblmeandClaude Opus 5	294b72d989	Let a pipeline swap one flow's nodes instead of being rebuilt ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01StpRc2C6au1WJ1EUU7fsfu	2026-08-23 17:41:14 +02:00
stroblmeandClaude Opus 5	60d7ec81c0	Rename the import package app to fluksio ... A wheel whose top-level module is `app` collides with anything else in a user's venv, so the package that is about to be published takes the name it is published under. Only the Python package moves; the repo, the Docker WORKDIR and the compose project keep theirs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 21:48:05 +02:00