2 Commits

Include renames

Author	SHA1	Message	Date
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