io.github.KD5RYN/b123d-print

- **Fair build slots on a shared server** (#73, #71): one client could fill every build slot and
  make everyone else wait (a 3 s `measure` took 28.5 s behind another client's six builds). The
  single first-come queue is replaced by a fair one (`sched.py`): a free slot goes to the client
  (token) with the fewest builds running, round-robin, and one client's own calls keep their
  order. `--quick-slots` (default 1 over HTTP with 2+ slots) keeps a slot for quick calls
  (`measure`, `section`, `list_faces`, `list_edges`, `hardware_list`), so they never wait behind
  long builds. `--client-jobs` (default 4 over HTTP) caps the calls one client may have running
  and waiting: more are refused at once with "server busy: you have 4 jobs running or queued
  ...; wait for one to finish", not queued without end, and a call that waited a whole
  `--timeout` for a slot is refused instead of starting after its client gave up. A `check`
  splits over at most 2 workers (3 on 4 cores was slower), and over 1 while another client
  waits. The worker container also claims queued jobs round-robin by client. `--max-builds`
  keeps its meaning: builds at once, all clients together. Over stdio and SSH (one client) the
  only change is the check split.
- **Memory limit per build** (#71): `--max-memory` / `B123D_PRINT_MAX_MEMORY` (default `2g`;
  `0` = no limit). A build over it fails with "the build used more than 2 GB of memory, the limit
  per job on this server" and the server and other builds go on, instead of the kernel's OOM
  killer taking other clients' builds with it. Linux: `RLIMIT_DATA`, set before bubblewrap starts
  so the job cannot raise it; Windows: the Job Object's memory limit; macOS has none. The Compose
  worker gets `mem_limit` (`B123D_PRINT_WORKER_MEMORY`, default `6g`) and `pids_limit: 1024` as
  the backstop, and a job the kernel kills is reported as most likely out of memory, not as a
  shutdown. `list_parts` reports the limits.

- **Uploads streamed to disk, a few at a time** (#132, #71): a signed upload link
  (`upload_reference`, `curl -fT`) used to collect the whole file, up to 50 MB, in the server's
  memory, with no limit on how many ran at once. Now the body goes to a hidden temp file next to
  the target (`ref/.<name>.<random>.part`) in pieces of about 1 MB and is renamed into place once
  it is all there and checked, so the file is never seen half written. Too large, refused, failed
  or cut off, the temp file is removed; one a stopped server left behind goes a day later.
  Chunked bodies work as well as ones with `Content-Length`. `--client-uploads` (default 2,
  `B123D_PRINT_CLIENT_UPLOADS`) and `--max-uploads` (default 8, `B123D_PRINT_MAX_UPLOADS`) cap
  uploads at once per token and in all; more are refused before the body is read with "server
  busy: ..." (HTTP 429 / 503). New links end in `?by=<token name>`, covered by the signature, so
  the cap counts the token that asked for the link; links from 0.3.11 still work until they
  expire (counted per workspace). Not-replacing links now cannot replace a file that another
  upload stored meanwhile (a hard link, which fails when the name exists). Every other check
  (signature, purpose, expiry, 50 MB, names, symlinks, content) is unchanged.

---
PyPI: https://pypi.org/project/b123d-print/0.3.12/ · Docker: `ghcr.io/kd5ryn/b123d-print-mcp:0.3.12`