Files
takana/scripts/farm
SergioandClaude Opus 5 5cfebf0087 granja: el aviso de "sin volumen" ahora CORTA en vez de sembrar igual
La noche del 2026-08-22 la campana corrio sharded en dos workers. Un volumen de
Hetzner se adjunta a UN server, y este script crea N workers en un bucle
apuntando todos al MISMO VOL_NAME: hworker-1 tomo harkaq-cosecha y para
hworker-2 no quedaba nada que adjuntar. Construyo el shard 1/2 entero en su
disco raiz y el dead-man se lo llevo a las 03:27Z. 21 G, 397 artefactos
sellados; 584 de sus 675 no existen en ningun otro sitio (work/perdidos-hworker2.txt).

Lo caro es que la deteccion YA ESTABA y era correcta:

    echo "   ⚠ el store NO quedó en el volumen ⇒ lo que construya se PIERDE..."

Ese aviso se imprimio, con esas palabras, y el script siguio adelante: armo el
dead-man y sembro la cola igual. Un aviso que no detiene el pipeline no es un
guardian cuando no hay nadie leyendo el log. Es la regla 3 del CLAUDE.md con
otra cara: el ausente (el volumen) llego hasta el final diciendo que todo fue
bien.

Tres cambios, todos sobre el mismo fallo:

  - `hcloud volume attach` dejaba de tragarse el error. Estaba escondido dos
    veces: `>/dev/null 2>&1` el mensaje y `|| true` el codigo de salida.
  - Se pregunta ANTES quien tiene el volumen tomado, y el motivo lo nombra.
  - Los dos ⚠ finales pasan a ser `sin_volumen`, que NO siembra: borra el server
    recien nacido (vacio, para que no quede idle facturando como hworker-4) y
    sale 1. Mismo blindaje que el dead-man y farm-down: solo borra con label
    role=hammer-worker, verificado que gioser no matchea.

Escape explicito para el caso deliberado: SIN_VOLUMEN_OK=1.

Verificado en negativo, que es como se comprueba lo que un guardian IMPIDE: la
llamada corta con exit 1 sin alcanzar la linea siguiente, y con un server sin
label no borra nada.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn
2026-08-23 17:13:09 +00:00
..