4 Commits

Include renames

Author	SHA1	Message	Date
stroblmeandClaude Opus 5.5	1090bcabfd	Quote names put into SDK client URL paths; share the helper with MCP ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013GAeg4Jo6xjZzjwy9QDWMQ	2026-10-06 17:23:49 +02:00
stroblmeandClaude Opus 5	d9630f66f5	Add POST /runs/import for runs executed elsewhere ... A history recorded before the move (MLflow experiments) had nowhere to go, since runs were only made by running a flow. Each entry is stored as it ended: parameters completed and checked like a submit, cause "import", empty commit and code digest, metrics and artifacts written as given, nothing queued or announced. Run.external_id (new migration) makes a second import a no-op and is an export column so a row joins back. The request is all or nothing and capped at 200 entries; Client.import_runs pages a longer history. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QgG6TJw5qBZzaLghQSRVrq	2026-09-16 17:01:07 +02:00
stroblmeandClaude Opus 5	51464941ac	Export runs and their curves as tables an analysis reads ... `fluksio export metrics` is the long table — a row per run, metric and step — and `fluksio export runs` the wide one, a row per run with the inputs that *vary* across the selection as columns beside its final numbers, status, duration and the commit and digest of the code it ran. Both carry the run id on every row, which is the join back to the run page and what makes an exported file auditable. `Client.export_metrics`/`export_runs` answer the same rows to a notebook. The engine streams csv or jsonl from two routes declared above `/{run_id}`; parquet is a client-side conversion behind the new `fluksio[parquet]` extra, so nobody pays for pyarrow who does not want dtypes kept. The long export reads each run through `_series`, so a cached node's curve comes with it, and `--stride` thins each series rather than the concatenation of all of them. Two things they needed on the way: `GET /runs` takes `?since=` and `?before=`, so a long history pages by the last row's own timestamp instead of an offset that shifts under it; and a read that reaches no engine now says so in half a second rather than seven, because `runs`, `flavors`, `export` and an unwatched `status` pass `retries=0`. Everything that submits keeps them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A9Hdrmf2cwNABCnE5x9UJa	2026-08-27 17:43:30 +02:00
stroblmeandClaude Opus 5	1f7c6646f1	Survive a busy engine: retry, idempotent submit, resilient waiting ... A driver script died of one slow answer: httpx.ReadTimeout out of RunHandle.refresh() with a 30 s read timeout and no retry anywhere, which cost a sweep 78 of its 84 runs. - Split the timeout (5 s connect, 120 s read): a wrong URL fails at once, and a busy engine gets longer than the slowest thing it does on purpose (a 60 s compile, a 15 s rebuild wait). - Retry idempotent calls three times on a transport error or 502/503/504. 503 is the engine's own "ask again" — it is what RebuildBusy answers. - Submit carries a key the engine stores with the run, so a retry after a timeout returns that run instead of starting a second. A sweep keys every entry, so a half-created one recreates only what is missing. - wait() and --follow tolerate five failed polls in a row; a 404 still stops at once, because that is an answer rather than a gap. - CLI says "engine not answering" and names the run still on the engine, instead of printing a traceback. - runs: clamp the params column to 80 characters; events() takes the flow/since/until the endpoint already had; RunHandle.failures answers "what killed this run" from the run's own node rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-26 21:19:09 +02:00