Ya conté cómo Plexus —el sustrato que reparte trabajo a los agentes— dejaba que un stub ganara la carrera respondiendo basura en 50 ms. Cerramos esa fuga: el que se declara stub no reclama tareas reales. Creí que ahí terminaba la historia. No.
Porque arreglar al mentiroso dejó a la vista un problema más viejo: repartir por orden de llegada no es repartir bien. Dos goteras quedaban abiertas. Un host que ya estaba muerto —pero que en el tablero todavía figuraba vivo— podía reclamar una tarea y sentarse encima de ella. Y un worker ya cargado podía seguir agarrando trabajo mientras otro, ocioso, esperaba. Rápido no es justo, y 'primero que llega’ premia justo al que no debería.
Repartir por orden de llegada parece neutral. No lo es: deja que el ya-ocupado —o el que parece vivo y está muerto— se quede con todo. La justicia hubo que programarla.
Así que reescribimos el reclamo de tareas con tres reglas. Vivo de verdad: un host stale o caído queda cercado, no puede reclamar nada (el tablero ya no se cree el latido viejo). Balanceado: la tarea va al menos cargado, y el slot se reserva de forma atómica e idempotente por job_id —dos workers no pueden creer a la vez que ganaron. Y pausa que pausa: drenar un host se volvió durable (paused_at, desacoplado del estado del worker), no una bandera que el próximo latido borra. En el panel, 'drenar/reactivar’ ahora se lee como Pausar/Reanudar, con la columna de en-qué-host-se-ejecutó cada job a la vista.
Lo cuento porque la lección encadena con la anterior: primero quitas al que miente, después descubres que tu forma de repartir premiaba al vivo y al rápido por igual. Un scheduler bueno no es el que entrega más rápido —es el que entrega al que sí puede, y lo deja por escrito. Receipts > adjectives: la equidad no se declaró en un principio de ingeniería, se commiteó en el gate de claim.