8 Commits

Include renames

Author	SHA1	Message	Date
stroblmeandClaude Opus 5	91ef2bbe9a	Key a node on the code it reaches, not on the repository around it ... `sync` follows each node function's imports through the project's own modules — stopping at the standard library, at anything installed, and at Fluksio itself, whose checkout would otherwise be most of every digest — and records the file list with what it hashed to. The engine hashes those files again when the run is claimed, so the fingerprint is live rather than a snapshot, and falls back to what sync recorded when it cannot see them: a remote worker's runs used to share one empty digest, and therefore one key. Three things follow. Editing a helper a node calls into re-runs that node, as before. Editing something the node never reaches no longer re-runs anything — a notebook two directories away was invalidating every arm. And `Run.code_digest` is now the hash of its nodes' digests, so it is neither looser nor tighter than "the code behind these numbers", which is what makes it worth joining an exported table on. `sync` says so too: it compares the per-node digest against the stored one, so a helper edit prints `train: updated (flow, fit)` instead of `unchanged`. The digest is read when the document is built rather than when the flow is declared, so a second `sync()` in one process sees an edit between them. Also: `fluksio runs` shows only the inputs that differ from what the flow declares, fitted to the terminal, so a flow taking a few kB of json no longer wraps every line. Every existing cache entry misses once — the fingerprint changed shape. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A9Hdrmf2cwNABCnE5x9UJa	2026-08-27 22:35:23 +02:00
stroblmeandClaude Opus 5	a82f88cf0a	Name the sizes a node can ask for ... Raw cpus and gpus are a property of the machines an installation has, so a node written against a cluster quietly stops meaning anything when the cluster is replaced. A node says "gpu-small" instead, and what that is stored here — editable, and read again every time the node is built, so changing the flavor changes what the next run gets. Memory joins the schema properly (`ram`, in MB, accepting "2G"), along with `duration_s` for how long a node is expected to take. That one is recorded and shown and nothing else yet: a statement for whoever is planning around the node, not a limit — the limit is still `timeout`. A flavor and a number for the same thing is refused, compared by value so an editor writing the whole object back with its defaults still round-trips. A name nothing stores is refused at the save, which covers the canvas and `fluksio sync` at once, and deleting one a node still asks for says which node. Four sizes are seeded on an installation that has none, and never re-seeded: re-adding one somebody deliberately removed is an argument nobody wins. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A6HeySA27EkGANZN95QySW	2026-08-27 08:59:10 +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	608d30d884	Let a node say how much of the machine it takes ... Five concurrent training nodes, each sizing its thread pool to every core, left the engine's own event loop unscheduled: the API stopped answering within 10 s and every client died. The same shape on a GPU deadlocked a run for 21 minutes at 0% utilisation with nothing failing and nothing to read -- it just sat in `running`. @node(resources={"cpus": 2}) is the declaration. The engine holds that much for the length of the execution, so more of them than the machine has room for wait their turn rather than oversubscribing it, and a `gpus` node holds its card exclusively. FLOW_CPUS defaults to every core but two, and those two are what keeps the engine answering. Because a thread cap is read when the process imports the library, a warm worker cannot be told a different one -- so an environment gets a pool of its own and nodes deriving the same one share it, rather than paying a cold start per call on exactly the nodes whose imports are slowest. XLA_FLAGS is never derived: it is a composed, version-dependent string, so it travels in resources.env where it is visible. A node that declares nothing is not accounted for and behaves as it always did -- it just gets FLOW_CPUS/FLOW_MAX_WORKERS as a thread cap, which is the half of this that fixes the reported incident without anybody declaring anything. An operator who set OMP_NUM_THREADS themselves still wins. Resources are claimed strictly before a worker slot, so the two blocking waits cannot deadlock. A node queued for them publishes node_queued and shows on GET /workers/resources, because waiting and hanging looked identical. Accounted, not enforced: no cgroups, no rlimits. Scheduling across machines, flavours and enforcement are the next steps. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-26 21:36:59 +02:00
stroblmeandClaude Opus 5	4941c2787c	Add fluksio status, and ask for a run's parameters at a terminal ... Two halves of the same gap: the CLI could start work but not show you any. `fluksio status` draws the home screen's top half in a terminal — health and what is wrong with it, every flow with its state and node count, and the recent runs and failures under them. `--watch` keeps it there. Rich does the drawing; it was already installed under fastapi's own CLI, and is named now because a command depends on it. `fluksio run` with no parameters at a terminal asks for them, one line per declared input with its declared value in brackets — so Enter through the lot is what running the defaults looks like, and an artifact input takes the `@run:` spelling the engine now resolves. A scripted run is untouched: passing any parameter, or piping the command, skips the questions, as does --defaults. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019V5bsYGNxcgPs4xXmTPx69	2026-08-25 07:42:09 +02:00
stroblmeandClaude Opus 5	93374a310e	Refuse what a node cannot publish, and stop timing out work that is fine ... Four things the python SDK turned up, each fixed where every client sees it. A key no port declares is now an error rather than a silent drop, on the return, the yield and the emit alike — the contract the docs already stated. The SDK reads literal yields at sync time, so a typo fails before anything runs, and an emission of one fails the call rather than being logged where nobody looks. NaN and infinity are refused at the port. JSON cannot spell either, so one that travelled came back as a 500, a socket frame that stopped the canvas, or a metric batch the database dropped whole. An artifact input takes `@run:<id>.<output>` or a bare digest, resolved on the engine — so the CLI, the run dialog and a python caller mean the same thing, and a sweep can pass one at all. Node timeouts are off by default. The clock measured silence, which a training node is full of, and remote workers had already stopped enforcing it — their heartbeat reset it. Now a heartbeat proves the agent rather than the node, ninety seconds of nothing fails the call either way, and the engine touches work it is still running so a long node is not redelivered at sixty seconds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019V5bsYGNxcgPs4xXmTPx69	2026-08-25 07:30:14 +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 Fable 5	a38e2745eb	Add a Python SDK: flows declared in your own repository ... A data scientist keeps their code where it is and decorates it: `@node` declares a function's ports beside the function, `Flow(name, nodes=[...])` says which of them make a flow, and `use(fn, wire=..., **settings)` rebinds one for a single flow. `fluksio sync` uploads the document plus a generated import shim per node, so the store still holds a complete, runnable, git-versioned definition while the code it imports stays theirs. `fluksio login|run|runs` and `flow.submit().wait()` are the client half, over the run endpoints that already existed. Runs record the user repository's commit beside the store's, so "what code produced this number" is answerable on the side that now holds the code. - `fluksio/sdk/`: ports, decorators, the flow builder and its checks, the shim generator, an HTTP client and sync. Standard library only at import, so `from fluksio import node` in a training script pulls in no engine. - `FlowDef.origin` marks a flow code-defined; `Run.origin_commit` carries the repository's commit; `POST /modules/refresh` retires the workers without an install, which every sync calls — a worker holds the imported package in memory, so an edit to it is invisible until the process goes. - The canvas shows a generated body read-only and names the repository to edit instead; a body edited there stops the next sync rather than being discarded. - The worker's reporter carries inert `Port`, `node`, `use` and `Flow`, since the shim imports a module whose first line declares them. - `examples/myresearch` is the worked example, `make sync-example` uploads it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012ue1tkFWB1bcGy3aWhCKpU	2026-08-23 20:16:08 +02:00