* fix(ubi-runner): an API error is never read as success on the money path (GST-1441)
A refused create disarms teardown, a 5xx/unanswered create is looked up by
name, down counts a VM gone only on a readable list, pull fails on ssh
failure, gc reports failed destroys, an unanswerable run record refuses
instead of starting a second VM, and the API key leaves curl's argv.
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* fix: pre-landing review fixes
A 5xx or unanswered create no longer adopts a VM another caller already holds under that name: up refuses a name that already answers show before any create is sent, and adopts after an ambiguous create only when the name was free just before it. Regression test reproduces the adopt-then-destroy on 6a61206.
Review-Finding: v1/outside-voice#1 reader=outside-voice
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* docs(troubleshooting): UBI_CREATE_UNKNOWN and UBI_ATTACH_UNKNOWN (GST-1441)
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* fix(ubi-runner): create only after the name check answers 404 (GST-1441 fix-check)
An unanswered name check let the create go out; a 5xx create whose lookup
then stayed unanswered left teardown armed on a VM whose owner was never
established, and one whose lookup answered 200 was disarmed and left to its
TTL. up now refuses before any request unless the check answers 404, so a
VM found after an ambiguous create is always this call's. The 409 test
again lists the holder (landing between check and create) and proves it is
not destroyed.
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
---------
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
