Upgrade von 0.26 auf 0.27

Upgrade von 0.26 → 0.27

Dies sind die ### Breaking-Einträge, die 0.27 für eine App auf Version 0.26 mit sich bringt.

Die beiden Cron-Änderungen sollten zuerst gelesen werden, da keine von ihnen den Start verhindert: Ein Job wird nun häufiger ausgeführt, und der andere stoppt vollständig. Die dritte betrifft nur eine Tabelle, die bereits existierte. Die vierte betrifft Rebase Cloud und begegnet Ihnen beim nächsten Deployment. Die letzte betrifft das Client-SDK im Browser.

---

97. Ein Cron-Schedule, der beide Tagesfelder einschränkt, greift bei jedem der beiden

0 9 1 * 1 wurde früher nur an einem Montag ausgeführt, der gleichzeitig der 1. des Monats war. Jetzt läuft er an jedem 1. und an jedem Montag, wie bei Standard-Cron üblich. Dies gilt, wenn keines der beiden Tagesfelder mit * beginnt. Ein Schedule mit * oder */n in einem der beiden Felder behält seine bisherige Bedeutung.

Der Schedule, den dies am stärksten verändert, ist das Idiom für den „ersten Montag des Monats“: 0 9 1-7 * 1 wurde früher einmal im Monat ausgelöst und wird nun an jedem der ersten sieben Tage sowie an jedem Montag ausgelöst.

Was zu ändern ist: Finden Sie die Schedules mit einer Zahl in beiden Tagesfeldern:

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

Wenn Sie einen beliebigen der beiden Tage meinten (ODER), belassen Sie es so. Wenn Sie beide meinten (UND), definieren Sie ein Tagesfeld im Schedule und prüfen Sie das andere im 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");
    },
});

Siehe Schedule-Syntax.

98. Ein Cron-Schedule mit einer fehlerhaften Zahl wird abgelehnt

5abc, */5x, 1.5 und ein rückwärts verlaufender Bereich wie 5-1 haben früher die Validierung bestanden. Eine Zahl wurde bis zum ersten Zeichen gelesen, das keine Ziffer war, sodass 5abc als 5 ausgeführt wurde und ein Rückwärtsbereich nichts beitrug. Jeder dieser Fälle wird nun unter Angabe des Felds und des Grundes abgelehnt.

Ein abgelehnter Job wird nicht registriert und nicht ausgeführt, während der Rest des Backends startet. Es gibt keinen weiteren Hinweis: Ein Deployment geht live, da die Datei selbst geladen wurde.

Was zu ändern ist: Suchen Sie nach dem Upgrade in den Server-Logs nach [cron] Rejecting job oder lesen Sie rejected bei GET /api/admin/cron aus, was auch das Cron-Jobs-Tool des Studios anzeigt. Korrigieren Sie die Zahl, und der Job wird beim nächsten Start registriert. Siehe Jobs, die nicht vorhanden sind.

99. Ein Schlüssel, dessen Strategie von seinem Typ nicht erfüllt werden kann, stoppt den Start

isId: "increment" bei einem Schlüssel, der keine number ist, und isId: "uuid" bei einem, der kein string ist, werden beim Laden der Konfiguration mit einer Meldung abgelehnt, die die Eigenschaft benennt. Beide wurden früher als roher SQL-Standardwert (DEFAULT) interpretiert. Postgres verweigerte DEFAULT increment beim ersten CREATE TABLE, daher betrifft dies nur bereits existierende Tabellen, bei denen diese Anweisung nicht ausgeführt wurde.

Was zu ändern ist: Deklarieren Sie den Schlüssel entsprechend dem tatsächlichen Spaltentyp. Ein numerischer Schlüssel verwendet type: "number" mit "increment", und ein Zeichenfolgenschlüssel verwendet "uuid", oder true, wenn der Aufrufer den Wert übergibt. Siehe String-Optionen.

100. Ein verwaltetes Deployment oder eine Preview schlägt fehl, wenn eine Funktions- oder Cron-Datei nicht geladen werden kann

Eine Funktions- oder Cron-Datei, die beim Importieren einen Fehler auslöste oder nicht geparst werden konnte, wurde früher übersprungen, sodass ein Deployment ✓ Live meldete und seine Probes bestand, während jede Route dieser Datei mit 404 antwortete. Pods in Rebase Cloud laufen jetzt mit REBASE_REQUIRE_FILES_LOADED (auf einer Runtime, die dies unterstützt), sodass die neue Version niemals den Status „ready“ erreicht, die alte Version weiterhin Anfragen bedient und das Deployment mit der Datei und dem Grund abbricht.

Ein Projekt, das bisher mit einer solchen Datei in Betrieb war, wird beim nächsten Deployment darauf stoßen. Fleet-Rollouts und Rollbacks sind davon nicht betroffen. Eine Datei, die fehlerfrei importiert wird und keine Funktion oder keinen Job exportiert (wie z. B. ein Helper), wird weiterhin übersprungen.

Was zu ändern ist: Führen Sie das Deployment durch und korrigieren oder löschen Sie dann die vom Deployment gemeldete Datei. Außerhalb von Rebase Cloud ändert sich nichts, es sei denn, Sie setzen REBASE_REQUIRE_FILES_LOADED=true selbst. Siehe Umgebung & Konfiguration.

101. Ein Browser-Client verwendet standardmäßig Cookie-Authentifizierung

createRebaseClient ohne auth.authFlowMode verwendete überall den JSON-Modus. Ein von der Rebase-Runtime betriebenes Backend speichert das Refresh-Token immer in einem HttpOnly-Cookie und antwortet im Response-Body mit "". Ein Browser-Client mit diesem Standardwert hatte somit nichts, womit er das Token erneuern konnte, und wurde etwa eine Stunde nach der Anmeldung wortlos abgemeldet. In einem Browser ist der Standard jetzt der Cookie-Modus. Außerhalb des Browsers sowie bei einem Browser-Client mit eigenem auth.storage bleibt es weiterhin JSON.

Was zu ändern ist: Nichts, wenn Ihr Backend auf der Rebase-Runtime läuft oder auth.cookieAuth setzt: Eine Browser-App, die nach einer Stunde abgemeldet wurde, bleibt nun angemeldet. Ein Backend ohne auth.cookieAuth benötigt auth: { authFlowMode: "json" } auf seinem Browser-Client. Der Client protokolliert beim ersten Login, bei dem beide Seiten nicht übereinstimmen, einen Fehler mit dem zu verwendenden Modus. Im Cookie-Modus wird die Sitzung nicht mehr in localStorage gespeichert; ein Neuladen stellt sie mit einer einzigen /auth/refresh-Anfrage wieder her, lesen Sie die Session daher nach auth.isInitialized(). Siehe Wo sich die Session befindet.