@tailor-platform/sdk 2.13.1 → 2.14.0

package/docs/services/tailordb-migration.md

@@ -115,7 +115,7 @@ A typical change cycle:
 
 ### Warnings and optional migration scripts
 
-Some non-breaking changes can still cause data loss — most notably removing a field (`field_removed`) or removing a table (`table_removed`). `migration generate` reports these as **warnings**:
+Some non-breaking changes can still cause data loss — most notably removing a field (`field_removed`), removing a table (`table_removed`), or removing a member inside a nested field (reported on the nested field's `field_modified` change). `migration generate` reports these as **warnings**:
 
 ```
 Warning: data loss possible:
@@ -164,7 +164,15 @@ During deploy, the pre-migration phase keeps the old field and adds the new fiel
 
 If you decline the prompt (or confirm the removal with `--drop`), the change stays a plain removal + addition with the usual data-loss warning.
 
-Renaming a member inside a **nested field** is not detected, and it is quieter: `User.address.zip` → `zipCode` becomes a single `field_modified` on `address` with no breaking change, no warning, and no generated script, so the member's values are not carried over. Copy them with a custom `tailordb migration script` if they must survive.
+Renaming a member inside a **nested field** is not detected as a rename: `User.address.zip` → `zipCode` becomes a single `field_modified` on `address`, so no `field_renamed` change is recorded and no copy script is generated. The removed member is reported as a data-loss warning instead, which `migration validate --strict` picks up like any other warning; when a compatible member was added at the same level, the warning names it as a possible rename target:
+
+```
+Warning: data loss possible:
+
+  - User.address.zip: Nested member removed (existing values will no longer be accessible through the schema). Possibly renamed to zipCode: nested renames are not detected, so copy its values with a migration script if it was renamed
+```
+
+To carry the values over, add a custom `tailordb migration script` to the migration. The pre-migration phase keeps the removed member on the nested field until the script finishes, exactly like a removed top-level field, so the script can read `zip` and write `zipCode`. Nested fields reach the script as objects, so the copy rewrites the whole `address` value; keep the old member in what you write, because it is still part of the schema until the post-migration phase drops it. Declare the new member as optional: the platform rejects a nested member that is required while existing records lack it, and nested member constraints are not relaxed during the pre-migration phase.
 
 ### Renaming a table
 
@@ -544,7 +552,7 @@ When you run `tailor deploy`, the SDK detects pending migrations (anything past
 
 For each pending migration:
 
-1. **Pre-migration**: Schema changes that would be breaking are applied in a relaxed form first. A verified in-place field type change keeps its complete previous field contract until Post-migration, including field and table-level hooks or validators changed by the same migration. Newly-required fields are added as optional; fields whose `optional → required` transition is breaking are temporarily kept optional. Fields that are being removed in this migration are temporarily kept on the table so that `migrate.ts` can still read them (for example, to `innerJoin` through a foreign key that is about to be dropped). For a renamed field, the old field is kept and the new field is added with its constraints relaxed, so the script can read the old field and write the new one. For a renamed table, the new table is created with its full constraints while the old table stays on the namespace until post-migration cleanup, so the script can copy rows between them. Breaking table-level index changes are relaxed the same way: a newly-added unique index is withheld, and an index gaining a unique constraint (or a unique index changing its field set) keeps its previous definition, so `migrate.ts` can resolve duplicates first. Non-breaking changes that are part of the same migration are also applied here.
+1. **Pre-migration**: Schema changes that would be breaking are applied in a relaxed form first. A verified in-place field type change keeps its complete previous field contract until Post-migration, including field and table-level hooks or validators changed by the same migration. Newly-required fields are added as optional; fields whose `optional → required` transition is breaking are temporarily kept optional. Fields that are being removed in this migration are temporarily kept on the table so that `migrate.ts` can still read them (for example, to `innerJoin` through a foreign key that is about to be dropped); members removed from a nested field are kept the same way. For a renamed field, the old field is kept and the new field is added with its constraints relaxed, so the script can read the old field and write the new one. For a renamed table, the new table is created with its full constraints while the old table stays on the namespace until post-migration cleanup, so the script can copy rows between them. Breaking table-level index changes are relaxed the same way: a newly-added unique index is withheld, and an index gaining a unique constraint (or a unique index changing its field set) keeps its previous definition, so `migrate.ts` can resolve duplicates first. Non-breaking changes that are part of the same migration are also applied here.
 2. **Script execution**: If `migrate.ts` exists on disk for this migration, it is bundled and sent to the platform via the script execution API and runs as the configured machine user inside a transaction. The script is hard-required for breaking changes (`diff.requiresMigrationScript`) — deploy fails if the file is missing, unless a `--no-script` acknowledgment was recorded (see [Breaking changes without a script](#breaking-changes-without-a-script)). It is also executed when present for warning-tier diffs — see [Warnings and optional migration scripts](#warnings-and-optional-migration-scripts).
 3. **Post-migration schema**: Required constraints and the target field definitions are applied. Do not assume that removing a field clears its underlying stored JSON value.
 4. **Checkpoint and cleanup**: The `sdk-migration` label is bumped to this migration's number, then removed GQL permissions and tables — including the old table left behind by a rename — are deleted. Advancing the checkpoint first prevents a failed checkpoint write from requiring the SDK to recreate irreversibly deleted records.
@@ -898,6 +906,20 @@ For genuinely different schemas across environments, prefer separate workspaces
 4. To force the remote schema back to a known snapshot, use `migration sync <N>` (see [`migration sync` Semantics](#migration-sync-semantics)).
 5. As a last resort in non-production environments, `--no-schema-check` skips both checks. Do not use this as a routine workaround.
 
+### "Remote migration checkpoint is not in the local migration history" error
+
+**Cause:** The deployed namespace's checkpoint refers to a migration number, or a migration history ID, that the local `migrations/` directory no longer has a record of. This is a different code path from schema drift above: it fires before any schema comparison, because the CLI cannot even locate the remote's recorded position in the local history.
+
+One specific cause is a `migration rebaseline` run on a different environment while this one had not yet caught up to the latest pre-rebaseline migration. `migration rebaseline` requires every other environment to already be at the latest migration (see [Re-baselining a deployed migration history](#re-baselining-a-deployed-migration-history)), but the CLI only verifies the one workspace it runs against. If this environment was behind, the error message names the migration this environment must reach (the migration every environment was required to be at before the rebaseline) alongside the migration it is actually at.
+
+**Resolution (fell behind before a rebaseline):**
+
+1. Restore the pre-rebaseline `migrations/` directory from git history — check out the commit before `migration rebaseline` ran. Re-baselining removes migration files after `0000` from the working tree but Git history retains everything that was committed.
+2. Deploy this environment against that restored history until its checkpoint reaches the migration named in the error, running any `migrate.ts` scripts it still needs.
+3. Switch back to the current (rebaselined) migration files and deploy again. The remote schema now matches the new baseline, so this deploy offers the automatic checkpoint reset to `0000` under the new history ID.
+
+**Resolution (any other cause):** Run `tailor tailordb migration status` to compare local and remote, or pull the latest migration files if your checkout is stale.
+
 ### "Invalid schema snapshot" or "Invalid migration diff" error
 
 **Cause:** A `schema.json` or `diff.json` file in the `migrations/` directory is corrupted or does not match the expected structure. Merge conflicts left in these files are a common cause.

package/docs/services/tailordb.md

@@ -116,6 +116,8 @@ Negative values follow the same rule based on absolute magnitude:
 
 ### Enum Fields
 
+Enum fields must define at least one allowed value. Empty arrays are rejected during `tailor deploy` and `tailor tailordb migration generate`.
+
 ```typescript
 db.enum(["red", "green", "blue"]);
 db.enum([

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/sdk",
-  "version": "2.13.1",
+  "version": "2.14.0",
   "description": "Tailor Platform SDK - The SDK to work with Tailor Platform",
   "license": "MIT",
   "repository": {
@@ -158,7 +158,7 @@
     "@inquirer/core": "12.0.1",
     "@inquirer/prompts": "8.7.0",
     "@jridgewell/trace-mapping": "0.3.31",
-    "@napi-rs/keyring": "1.3.0",
+    "@napi-rs/keyring": "2.0.0",
     "@opentelemetry/api": "1.9.1",
     "@opentelemetry/exporter-trace-otlp-proto": "0.221.0",
     "@opentelemetry/resources": "2.10.0",

package/dist/application-BFTkaW6X.mjs

@@ -1 +0,0 @@
-import{n as e,t}from"./application-D3HlhR3i.mjs";export{t as defineApplication,e as generatePluginFilesIfNeeded};