Actualización de 0.26 a 0.27

Actualización de 0.26 → 0.27

Estas son las entradas ### Breaking que 0.27 incluye para una aplicación en 0.26.

Los dos cambios en cron son los primeros que deben leerse, ya que ninguno impide que nada arranque: un trabajo comienza a ejecutarse con más frecuencia y el otro deja de ejecutarse por completo. El tercero solo afecta a una tabla que ya existía. El cuarto corresponde a Rebase Cloud y te lo encontrarás en tu próximo despliegue. El último es el SDK del cliente en un navegador.

---

97. Una programación cron que restringe ambos campos de día coincide con cualquiera de los dos

0 9 1 * 1 solía ejecutarse solo los lunes día 1. Ahora se ejecuta cada día 1 y cada lunes, tal como lo hace el cron estándar. Esto aplica cuando ninguno de los dos campos de día comienza con *. Una programación con * o */n en cualquiera de ellos mantiene el comportamiento que tenía.

La programación que más cambia con esto es el patrón del “primer lunes del mes”: 0 9 1-7 * 1 solía ejecutarse una vez al mes, y ahora se ejecuta en cada uno de los primeros siete días y todos los lunes.

Qué cambiar: busca las programaciones que tengan un número en ambos campos de día:

grep -rnE "schedule:.*[\"'\`][^ ]+ +[^ ]+ +[0-9][^ ]* +[^ ]+ +[0-9]" backend/

Si tu intención era cualquiera de los dos días, déjalo así. Si te referías a ambos, programa un campo de día y evalúa el otro en el handler:

// backend/crons/first-monday.ts
import { defineCron } from "@rebasepro/server";

export default defineCron({
    schedule: "0 9 * * 1",
    timezone: "UTC",

    async handler(ctx) {
        if (ctx.scheduledAt.getUTCDate() > 7) return;
        ctx.log("First Monday of the month");
    },
});

Consulta Sintaxis de programación.

98. Se rechaza una programación cron con un número mal formado

5abc, */5x, 1.5 y un rango en orden inverso, como 5-1, antes pasaban la validación. Los números se leían hasta el primer carácter que no fuera un dígito, por lo que 5abc se ejecutaba como 5, y un rango inverso no aportaba nada. Ahora cada uno de estos casos es rechazado indicando el campo y el motivo.

Un trabajo rechazado no se registra ni se ejecuta, y el resto del backend arranca. Nada más te avisa: el despliegue pasa a estar activo (live) porque el archivo en sí se cargó.

Qué cambiar: después de actualizar, busca [cron] Rejecting job en los registros del servidor, o consulta rejected en GET /api/admin/cron, que la herramienta Cron Jobs de Studio también muestra. Corrige el número y el trabajo se registrará en el siguiente arranque. Consulta Trabajos que no están allí.

99. Una clave cuya estrategia no puede ser cumplida por su tipo detiene el arranque

isId: "increment" en una clave que no es de tipo number, e isId: "uuid" en una que no es string, se rechazan al cargar la configuración con un mensaje que nombra la propiedad. Anteriormente, ambos se leían como un valor predeterminado directo de SQL. Postgres rechazaba DEFAULT increment en el primer CREATE TABLE, por lo que esto solo afecta a una tabla que ya existía, donde nada llegó a ejecutar esa sentencia.

Qué cambiar: declara la clave con el tipo real de la columna. Una clave numérica requiere type: "number" con "increment", y una clave de cadena requiere "uuid", o true cuando quien realiza la llamada proporciona el valor. Consulta Opciones de cadenas.

100. Un despliegue o vista previa gestionada falla cuando un archivo de función o de cron no se carga

Un archivo de función o de cron que lanzaba un error o no se podía parsear al importarse solía omitirse, por lo que un despliegue reportaba ✓ Live y pasaba sus sondeos mientras cada ruta de ese archivo respondía 404. Los pods en Rebase Cloud ahora se ejecutan con REBASE_REQUIRE_FILES_LOADED, en un runtime que cuenta con ello, de modo que la nueva versión nunca pasa a estar lista, la versión anterior continúa dando servicio y el despliegue finaliza señalando el archivo y el motivo.

Un proyecto que haya estado funcionando con un archivo de este tipo se topará con esto en su próximo despliegue. Los rollouts de flota y los rollbacks no están sujetos a esto. Un archivo que se importa limpiamente y no exporta ninguna función o trabajo, como un helper, se sigue omitiendo.

Qué cambiar: despliega y luego corrige o elimina el archivo que indique el despliegue. Fuera de Rebase Cloud nada cambia a menos que configures REBASE_REQUIRE_FILES_LOADED=true por tu cuenta. Consulta Entorno y configuración.

101. El cliente del navegador usa autenticación por cookies por defecto

createRebaseClient sin auth.authFlowMode usaba el modo json en todas partes. Un backend ejecutado por el runtime de Rebase siempre guarda el token de actualización (refresh token) en una cookie HttpOnly y devuelve "" en el cuerpo de la respuesta, por lo que un cliente en el navegador con esa configuración por defecto no disponía de nada con qué renovar la sesión y se le cerraba la sesión sin previo aviso aproximadamente una hora después de iniciarla. En un navegador, el valor predeterminado ahora es el modo cookie. Fuera del navegador, y en un cliente de navegador al que se le proporcione su propio auth.storage, sigue siendo json.

Qué cambiar: nada, cuando tu backend se ejecuta en el runtime de Rebase o configura auth.cookieAuth: una aplicación de navegador en la que se cerraba la sesión después de una hora permanecerá con la sesión iniciada. Un backend sin auth.cookieAuth necesita auth: { authFlowMode: "json" } en su cliente de navegador. El cliente registra un error indicando el modo a utilizar en el primer inicio de sesión donde ambos difieren. En el modo cookie, la sesión ya no se guarda en localStorage; al recargar la página se restaura con una solicitud a /auth/refresh, por lo que debes leer la sesión después de auth.isInitialized(). Consulta Dónde reside la sesión.