Saltar a contenido

Novedades de 0.6.1

Publicada el 2026-10-04: SDK Python rayito 0.6.1, SDK TypeScript rayito 0.6.1 y rayd 0.6.1.

Una release de correcciones sobre 0.6.0. Ninguna cambia la API pública, pero tres cambian un comportamiento que conviene conocer: redesplegar una pila, reincarnate() y los procesos que se demonizan dentro del sandbox. Actualizar es recomendable para todo el que use una función de 0.6.0.

Redesplegar una pila conserva sus parámetros

OptionalStacks.deploy() (y rayito stack deploy) sobre una pila que ya existe la actualiza. Hasta 0.6.0, cada parámetro que no repetías volvía a su valor por defecto del catálogo: redesplegar s3-mounts sin Prefixes volvía a abrir todo el bucket, metadata-index sin TableName reemplazaba (y borraba) la tabla y secrets-access sin KmsKeyArn quitaba kms:Decrypt.

Desde 0.6.1, los valores por defecto sólo se aplican al crear la pila. Al actualizarla, cada parámetro que no pasas y la pila ya tiene se manda con UsePreviousValue de CloudFormation: conserva el valor desplegado. Para ver qué cambiaría antes de desplegar, parameter_changes() (TypeScript: parameterChanges()) hace sólo un DescribeStacks:

from rayito import OptionalStacks

stacks = OptionalStacks(region="us-east-1")
for change in stacks.parameter_changes("s3-mounts", parameters={"ReadOnly": "false"}):
    print(change.name, change.before, "->", change.after)  # sólo ReadOnly
stacks.deploy("s3-mounts", parameters={"ReadOnly": "false"})  # Prefixes se conserva

import { OptionalStacks } from "rayito";

const stacks = new OptionalStacks({ region: "us-east-1" });
const changes = await stacks.parameterChanges("s3-mounts", {
  parameters: { ReadOnly: "false" },
});
for (const change of changes) console.log(change.name, change.before, "->", change.after);
await stacks.deploy("s3-mounts", { parameters: { ReadOnly: "false" } });

rayito stack deploy s3-mounts --param ReadOnly=false
# imprime los parámetros que cambian (aquí sólo ReadOnly) antes de pedir confirmación

Si redesplegaste una pila con 0.6.0 sin repetir todos sus parámetros, revisa su configuración con rayito stack status <componente> y vuelve a desplegarla con los valores que quieres.

reincarnate() reaplica todas las opciones 0.6

reincarnate() lanza un sucesor con el mismo HOME cuando un sandbox se acerca a su tope de 8 h (Persistencia). En 0.6.0 sólo reenviaba gateways=, así que el sucesor perdía mounts=, events= y telemetry= sin avisar. Desde 0.6.1, create() recuerda sus opciones 0.6 y reincarnate() las aplica en el único ConfigureSandbox del sucesor, resueltas con los datos del sandbox nuevo:

Opción En el sucesor
mounts= vuelve a montar cada bucket; reincarnate() no devuelve hasta que todos están mounted
events= deriva una clave de eventos nueva del nuevo sandbox_id; nunca reutiliza la del original
telemetry= usa la imagen y la memoria del sucesor en los atributos de recurso
gateways= relee cada cabecera de Secrets Manager; nunca reenvía un valor ya leído
size= no se repite: el tamaño ya va en el ARN de la imagen que se relanza

Si una sección falla en el sucesor, se termina (salvo keep_on_failure) y el sandbox original sigue vivo, como ante cualquier otro fallo de create(). Sin código que cambiar: es el mismo reincarnate().

rayd recoge los procesos zombi

rayd es el PID 1 del sandbox. Hasta 0.6.0, un proceso que se demoniza (doble fork, nohup … & dentro de un subshell, un servidor que se pasa a segundo plano) quedaba como <defunct> colgado de rayd durante toda la vida del sandbox. Con rayd 0.6.1, rayd los recoge en cuanto terminan.

Lo que esto no cambia:

  • Los códigos de salida de tus comandos, terminales, kernels y montajes nunca se pierden: rayd registra cada hijo propio antes de que el reaper pueda verlo, y el reaper sólo recoge procesos huérfanos que no son suyos.
  • No hay ninguna opción nueva ni ningún coste: el reaper se activa solo cuando rayd es el PID 1, en cada SIGCHLD y cada 5 s.

Necesita una imagen con rayd 0.6.1: republícala (Imágenes). Con una imagen anterior, los zombis no consumen CPU ni memoria, sólo una entrada en la tabla de procesos (Solución de problemas).

Otras correcciones

  • Webhooks: el guardián SSRF del deliverer clasifica una IPv6 que encapsula una IPv4 (::ffff:100.64.0.1, de un registro AAAA) como esa IPv4, así que el rango CGNAT queda bloqueado también por esa vía. Para tenerlo, redespliega la pila: rayito events deploy sube el código nuevo de las Lambdas.
  • Mensajes: volumes= y domain= lanzan UnimplementedError con "todavía no disponible" (antes decía "llega en 0.6"). rayito domain ya no aparece en rayito --help, y rayito template, rayito stack y rayito events tienen texto de ayuda en cada subcomando.
  • TypeScript para CommonJS: "rayito" y "rayito/e2b" declaran el types de cada condición (import → .d.mts, require → .d.cts), así un proyecto CommonJS con moduleResolution: node16 recibe los tipos del fichero que de verdad carga. Mismos ficheros en tiempo de ejecución.
  • TypeScript: se exporta WorkdirStep desde rayito, como en Python.
  • Documentación: bloques "Coste y activación" completos para mounts/S3Mount y size, también en el hover del IDE en TypeScript.

Cómo actualizar desde 0.6.0

pip install -U "rayito[cli]"

pnpm add rayito@latest

Republica tu imagen para el reaper de rayd 0.6.1 y redespliega la pila events-webhooks si la usas. Nada más: la serie de compatibilidad sigue siendo 0.6 y un SDK 0.6.1 funciona con una imagen de rayd 0.6.0.

Detalle completo: Changelog.