A batch run skips the nodes waiting on a failed one and ends error; a run whose nodes cannot load fails with the load error before anything executes; cancelling a run stops its pipeline without announcing a pause of the live flow; batch_issues refuses a delay node's interval; the client accepts an engine URL with or without /api/v1; RedisState's compare-and-swap records the names it writes

docs/code/cli.md

@@ -151,7 +151,8 @@ Client commands use the nearest `.fluksio/client.json`, or the global
 configuration when there is no project instance. Legacy client configuration
 is a fallback.
 `FLUKSIO_URL` and `FLUKSIO_TOKEN` override saved values; command options
-`--url` and `--token` override both.
+`--url` and `--token` override both. An engine URL works with or without
+the `/api/v1` path.
 
 A client needs an engine at least as new as itself. An engine from before
 flow ids cannot create flows the way this client does, and the client says

docs/concepts/runs.md

@@ -18,9 +18,14 @@ A batch flow does not need activation and does not open subscriptions,
 schedules or webhooks. A run executes each node once after its dependencies
 finish. Missing parameters use their declared initial values.
 
+When a node fails, the nodes that wait on it are recorded as `skipped` and
+the run ends `error`. A node that cannot be loaded fails the run before
+anything executes, with the node's load error as the reason.
+
 Non-streaming ports cannot use `interval` in a batch flow: there is no timer
-to deliver a delayed value. Streaming ports can use it to reduce display
-updates while keeping every metric point.
+to deliver a delayed value. The same goes for a delay node's `interval`
+setting. Streaming ports can use it to reduce display updates while keeping
+every metric point.
 
 ## Submitting