vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

Roll back stored settings when a creation fails, and keep form ids unique

Browse source 
create_agent puts back the caps and inference settings it replaced if a
later store or the job insert fails, so a refused creation leaves nothing
behind for the name. The shared field components take an id prefix so the
create dialog and an open editor never share a DOM id. The queue check now
follows the hive roster check, the 422 is documented, and the copy says
empty rather than closed and that destroy keeps stored settings.
This commit is contained in:
iris 2026-10-15 11:44:16 +02:00 • committed by mara
commit 37c91eb916
7 changed files with 288 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

20
docs/swarm/ui.md
View file

@ -299,14 +299,18 @@ sets the hive's own limits.
### Settings at creation
The **+ agent** dialog has two collapsed sections, **resource caps** and
**inference**, with the same fields as the detail panel's editors. Leave them
closed or empty and the request is the plain name and hive. Fill them and
`POST /api/agents` carries them as optional `limits` and `inference` objects,
the same shapes the two `PUT` routes take. The controller checks them with the
`PUT` rules before it queues anything, so a bad value gets a refusal with its
reason and creates no agent. It stores them ahead of the job graph, so they
are in place before the agent first runs. Creating a name that already exists with no settings
leaves any stored ones alone.
**inference**, with the same fields as the detail panel's editors. Leave the
fields empty and the request is the plain name and hive; collapsing a section doesn't
withdraw what you typed in it. Fill them and `POST /api/agents` carries them
as optional `limits` and `inference` objects, the same shapes the two `PUT`
routes take. The controller checks them with the `PUT` rules before it queues
anything, so a bad value gets a refusal with its reason and creates no agent.
It stores them ahead of the job graph, before it declares the agent, so they
are in place before the agent first runs. If the creation then fails, the
controller puts back what it replaced. Each agent name keys its settings and
destroying an agent doesn't clear them, so a name set up before keeps its
stored settings when you leave the fields empty.
### Linking external accounts