REPORT: record that Gitea soft-deletes runners, and the query trap that hid it

2026-08-02 16:38:35 +02:00
parent ca3c8f6784
commit c04ea4f6c2
1 changed files with 9 additions and 1 deletions
@@ -167,7 +167,15 @@ measured at **11.9 MiB RSS, 0.98 s wall**.
 3. **The Gitea-side registration records — the layer this project has missed four times.**
   - The **P6b orphan** (`id=1`) was deleted **immediately when it was created**, not left for the
     end: `DELETE /api/v1/admin/actions/runners/1 → 204`.
-   - **Final runner list: exactly one, the intended live runner** — see §12 for the closing check.
+   - **Final runner list: exactly one, the intended live runner** —
+     `id=2 felhom-gates-runner status=online labels=[felhom-gates]`, and the live pod's own
+     `/data/.runner` carries `id=2`, so the record and the process agree.
+     **A trap worth recording, because it briefly looked like a failed teardown:** a raw
+     `select id,name from action_runner` returns **two** rows. Gitea **soft-deletes** runners — the
+     deleted row is tombstoned (`deleted` set), not removed, and the admin API correctly reports one.
+     The query without the tombstone filter was the misleading instrument, not the teardown. Same
+     class as the `| tail -5` census bug and the `go test -run` filter: **a query that does not model
+     the deletion semantics is not a check.**
   - The **temporary probe workflow** `.gitea/workflows/probe.yml` was deleted from `main` in
     `666a34d`, the same commit that added the real one.
   - The **admin API access token** minted for this session (used to read run conclusions and to