@tailor-platform/sdk 2.38.0 → 2.39.0

package/docs/cli/application.md

@@ -42,9 +42,9 @@ tailor generate [options]
 
 **Options**
 
-| Option              | Alias | Description             | Required | Default              |
-| ------------------- | ----- | ----------------------- | -------- | -------------------- |
-| `--config <CONFIG>` | `-c`  | Path to SDK config file | No       | `"tailor.config.ts"` |
+| Option              | Alias | Description                | Required | Default              | Env                  |
+| ------------------- | ----- | -------------------------- | -------- | -------------------- | -------------------- |
+| `--config <CONFIG>` | `-c`  | Path to Tailor config file | No       | `"tailor.config.ts"` | `TAILOR_CONFIG_PATH` |
 
 See [Global Options](../cli-reference.md#global-options) for options available to all commands.
 

package/docs/cli/executor.md

@@ -172,16 +172,16 @@ tailor executor trigger [options] <executor-name>
 
 **Options**
 
-| Option                          | Alias | Description                                                                        | Required | Default | Env                            |
-| ------------------------------- | ----- | ---------------------------------------------------------------------------------- | -------- | ------- | ------------------------------ |
-| `--workspace-id <WORKSPACE_ID>` | `-w`  | Workspace ID                                                                       | No       | -       | `TAILOR_PLATFORM_WORKSPACE_ID` |
-| `--profile <PROFILE>`           | `-p`  | Workspace profile                                                                  | No       | -       | `TAILOR_PLATFORM_PROFILE`      |
-| `--data <DATA>`                 | `-d`  | Request body (JSON string)                                                         | No       | -       | -                              |
-| `--header <HEADER>`             | `-H`  | Request header (format: 'Key: Value', can be specified multiple times)             | No       | -       | -                              |
-| `--wait`                        | `-W`  | Wait for job completion and downstream execution (workflow/function) if applicable | No       | `false` | -                              |
-| `--interval <INTERVAL>`         | `-i`  | Polling interval when using --wait (e.g., '3s', '500ms', '1m')                     | No       | `"3s"`  | -                              |
-| `--timeout <TIMEOUT>`           | `-t`  | Maximum time to wait when using --wait (e.g., '30s', '5m')                         | No       | `"5m"`  | -                              |
-| `--logs`                        | `-l`  | Display function execution logs after completion (requires --wait)                 | No       | `false` | -                              |
+| Option                          | Alias | Description                                                                                             | Required | Default | Env                            |
+| ------------------------------- | ----- | ------------------------------------------------------------------------------------------------------- | -------- | ------- | ------------------------------ |
+| `--workspace-id <WORKSPACE_ID>` | `-w`  | Workspace ID                                                                                            | No       | -       | `TAILOR_PLATFORM_WORKSPACE_ID` |
+| `--profile <PROFILE>`           | `-p`  | Workspace profile                                                                                       | No       | -       | `TAILOR_PLATFORM_PROFILE`      |
+| `--data <DATA>`                 | `-d`  | Request body (JSON string)                                                                              | No       | -       | -                              |
+| `--header <HEADER>`             | `-H`  | Ignored, as the executor receives empty headers (format: 'Key: Value', can be specified multiple times) | No       | -       | -                              |
+| `--wait`                        | `-W`  | Wait for job completion and downstream execution (workflow/function) if applicable                      | No       | `false` | -                              |
+| `--interval <INTERVAL>`         | `-i`  | Polling interval when using --wait (e.g., '3s', '500ms', '1m')                                          | No       | `"3s"`  | -                              |
+| `--timeout <TIMEOUT>`           | `-t`  | Maximum time to wait when using --wait (e.g., '30s', '5m')                                              | No       | `"5m"`  | -                              |
+| `--logs`                        | `-l`  | Display function execution logs after completion (requires --wait)                                      | No       | `false` | -                              |
 
 **Examples**
 
@@ -197,12 +197,6 @@ $ tailor executor trigger my-executor
 $ tailor executor trigger my-executor -d '{"message": "hello"}'
 ```
 
-**Trigger with data and headers**
-
-```bash
-$ tailor executor trigger my-executor -d '{"message": "hello"}' -H "X-Custom: value" -H "X-Another: value2"
-```
-
 **Trigger and wait for completion**
 
 ```bash
@@ -271,7 +265,9 @@ if (result.timedOut) {
 Only executors with `INCOMING_WEBHOOK` or `SCHEDULE` trigger types can be triggered manually.
 Executors with `EVENT` trigger types (such as `recordCreated`, `recordUpdated`, `recordDeleted`) cannot be triggered manually.
 
-The `--data` and `--header` options are only available for `INCOMING_WEBHOOK` trigger type.
+The `--data` and `--header` options are accepted only for `INCOMING_WEBHOOK` trigger type.
+
+The executor receives the `--data` JSON as `body`, with empty `headers` and no `rawBody`. `--header` values are not passed to the executor. To test an executor that reads headers or verifies a signature over `rawBody`, send the request to its webhook URL, which `executor webhook list` shows.
 
 **Downstream Execution Tracking**
 

package/docs/cli/function.md

@@ -172,7 +172,7 @@ tailor function run [options] <file>
 | `--name <NAME>`                 | `-n`  | Workflow job name to run (matches the `name` field of createWorkflowJob)                       | No       | -                    | -                                   |
 | `--arg <ARG>`                   | `-a`  | JSON argument to pass to the function                                                          | No       | -                    | -                                   |
 | `--machine-user <MACHINE_USER>` | `-m`  | Machine user name for authentication. Falls back to the active profile's default machine user. | No       | -                    | `TAILOR_PLATFORM_MACHINE_USER_NAME` |
-| `--config <CONFIG>`             | `-c`  | Path to SDK config file                                                                        | No       | `"tailor.config.ts"` | -                                   |
+| `--config <CONFIG>`             | `-c`  | Path to Tailor config file                                                                     | No       | `"tailor.config.ts"` | `TAILOR_CONFIG_PATH`                |
 | `--allow-schema-drift`          | -     | Run a scaffolded script even when its schema snapshot no longer matches                        | No       | `false`              | -                                   |
 
 See [Global Options](../cli-reference.md#global-options) for options available to all commands.

package/docs/cli/workspace.md

@@ -201,10 +201,9 @@ tailor workspace prune [options]
 | --------------------------------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------- | ------- | ------------------------- |
 | `--name <NAME>`                         | -     | Select workspaces whose whole name matches this regular expression (repeatable)                                                            | No       | -       | -                         |
 | `--older-than <OLDER_THAN>`             | -     | Minimum age since creation, such as 30m, 24h, or 7d. 0s disables the age check and requires a location. Required unless --expired is given | No       | -       | -                         |
-| `--expired`                             | -     | Select workspaces whose own --ttl expiry has passed, instead of by name and age. Requires --organization-root, --folder-id, or --personal  | No       | `false` | -                         |
+| `--expired`                             | -     | Select workspaces whose own --ttl expiry has passed, instead of by name and age. Requires --organization-root or --folder-id               | No       | `false` | -                         |
 | `--organization-root <ORGANIZATION_ID>` | -     | Consider the workspaces directly under this organization, excluding those in its folders (repeatable)                                      | No       | -       | -                         |
 | `--folder-id <FOLDER_ID>`               | -     | Consider the workspaces in this folder (repeatable)                                                                                        | No       | -       | -                         |
-| `--personal`                            | -     | Consider the workspaces belonging to no organization and no folder                                                                         | No       | `false` | -                         |
 | `--exclude <EXCLUDE>`                   | -     | Keep a workspace with this exact name even when it matches (repeatable)                                                                    | No       | -       | -                         |
 | `--limit <LIMIT>`                       | -     | Abort when more workspaces match than this, without deleting anything. 0 removes the cap                                                   | No       | `20`    | -                         |
 | `--dry-run`                             | -     | List the workspaces that would be deleted without deleting them                                                                            | No       | `false` | -                         |
@@ -219,7 +218,7 @@ Use this to reclaim workspaces left behind by CI runs, preview deployments, or i
 
 With --expired the workspaces select themselves instead: each one is deleted only once the --ttl expiry it recorded at creation has passed, so callers need no --name or --older-than. A workspace that records no expiry is never deleted this way, and neither is one whose recorded expiry cannot be read. Because that expiry is recorded on the workspace rather than derived from its name, anything able to write the workspace's metadata can bring its deletion forward -- and writing a workspace's metadata is a lesser permission than deleting it. --expired therefore requires at least one location, and --name still applies on top.
 
-Every workspace lives in exactly one location, and the location options name them explicitly: --organization-root selects the workspaces directly under an organization and none inside its folders, --folder-id selects the workspaces in one folder, and --personal selects the workspaces belonging to no organization and no folder. Each option can be given more than once, they combine as a union, and none of them is read from the environment or from the default organization/folder set by `user update` -- a sweep covers exactly the locations spelled out on the command line. Selecting --personal is a deliberate choice to accept, for every organization-less workspace visible to this login, the expiry that anyone able to write a workspace's metadata may have recorded. Without any location option, a --name / --older-than sweep considers every visible workspace.
+Every workspace lives in exactly one location, and the location options name them explicitly: --organization-root selects the workspaces directly under an organization and none inside its folders, and --folder-id selects the workspaces in one folder. Each option can be given more than once, they combine as a union, and none of them is read from the environment or from the default organization/folder set by `user update` -- a sweep covers exactly the locations spelled out on the command line. Without any location option, a --name / --older-than sweep considers every visible workspace.
 
 Without a location option, prune warns before listing workspaces that every workspace visible to this login is a candidate for the name and age filters, even with --yes or --dry-run. The default organization/folder set by `tailor user update` is not used.
 

package/docs/configuration.md

@@ -265,6 +265,34 @@ When using external resources:
 - Destructive operations like `tailordb truncate` (and `tailor seed apply --truncate`) automatically exclude external resources to prevent accidental data loss in shared resources
 - Subscribing an executor to an external resource's events requires the config that owns the resource in the same `deploy`. Publishing is then enabled automatically, and `deploy` records the dependency so a later deploy without that config asks for confirmation instead of silently turning publishing off
 
+#### Referencing another app's Auth with `asExternal()`
+
+When the other app is in the same repository, import its `defineAuth` result and call `asExternal()` instead of writing the name by hand.
+
+```typescript
+// core/auth.ts
+export const auth = defineAuth("core-auth", {
+  machineUsers: { portal: { attributes: { role: "STAFF" } } },
+  // ...
+});
+```
+
+```typescript
+// portal/tailor.config.ts
+import { auth as coreAuth } from "../core/auth";
+
+export default defineConfig({
+  name: "portal",
+  auth: coreAuth.asExternal(),
+});
+```
+
+- The reference follows renames of the Auth service and of its machine users.
+- The machine user names reach the generated `tailor.d.ts`, so a misspelled `invoker` is a type error in the referencing app, including when it is written as an expression such as `flag ? "portal" : "other"`.
+- Only the name and the machine users are taken over. Hooks, OAuth2 clients, and the rest of the definition stay with the app that owns the Auth service, so this project does not deploy them a second time.
+- Put the `defineAuth` call in its own file, as above. Importing the other app's `tailor.config.ts` also runs the rest of that file.
+- An Auth service defined in another repository cannot be imported. Reference it with `{ name: "...", external: true }`; `invoker` then accepts any string.
+
 ### Built-in IdP
 
 Configure the Built-in IdP service using `defineIdp()`. See [IdP](./services/idp.md) for full documentation.

package/docs/github-actions.md

@@ -333,14 +333,24 @@ pull request is closed no longer runs, because that workflow no longer starts
 then; move it into the cleanup workflow. `setup` warns about each job of yours
 in the preview workflow whose `if` contains an `== 'closed'` comparison.
 
-Fork pull requests are skipped. Every other pull request gets a preview, draft
-pull requests included. `--require` narrows that to one of:
+#### Pull requests that get a preview
+
+Fork pull requests are skipped, and so are events on a closed pull request,
+such as a label added after merging. Every other pull request gets a preview,
+draft pull requests included. `--require` narrows that to one of:
 
 - `--require ready` skips draft pull requests. The preview is deployed when the
   draft is marked ready for review.
 - `--require label` deploys only pull requests labeled `tailor:preview`. A
   labeled draft deploys too, because the label asks for the preview.
 
+With app directories other than the repository root (`--dir`), a pull request
+gets no preview either when none of its changed files counts. A file counts
+when it is under an app directory, is the generated workflow file, or matches a
+`--paths` pattern, and the last pattern that matches it does not start with `!`
+(see
+[Running on changes outside the app directories](#running-on-changes-outside-the-app-directories)).
+
 When `tailor setup update` regenerates a preview target generated before
 `--require` existed, it reads the target as `--require ready`, or as
 `--require label` if it required the label. The first keeps skipping drafts; the
@@ -362,7 +372,8 @@ tailor setup ci autofix --dir apps/erp --dir apps/users  # run tailor generate i
 It writes `.github/workflows/tailor-autofix.yml`, which runs `tailor generate`
 on every pull request and, when that changes files, commits them to the pull
 request branch as `chore: run tailor generate`. Only the changes
-`tailor generate` makes are committed: files that earlier steps leave in the
+`tailor generate` makes, and with `--codemod deterministic` those of
+`tailor upgrade`, are committed: files that earlier steps leave in the
 checkout, such as an `.npmrc`, are not. The deploy workflows keep their check,
 which fails on the commit that needed the fix and passes on the fix commit.
 
@@ -387,9 +398,10 @@ right away.
 - **A branch that moved on:** if someone pushes to the branch while the
   workflow runs, it does not commit; the run for the new commit regenerates the
   files.
-- **Output that keeps changing:** if `tailor generate` changes files again
-  right after the fix commit, the workflow fails instead of committing again.
-  Check that running it twice in a row changes nothing.
+- **Output that keeps changing:** if `tailor generate` (or, with
+  `--codemod deterministic`, `tailor upgrade`) changes files again right after
+  the fix commit, the workflow fails instead of committing again. Check that
+  running it twice in a row changes nothing.
 - **Approval rules:** the fix commit becomes the most recent push to the pull
   request, and a bot pushed it. A branch protection rule that requires the most
   recent push to be approved by someone other than its pusher is then satisfied
@@ -414,6 +426,60 @@ right away.
 To stop committing, delete the workflow with
 `tailor setup delete .github/workflows/tailor-autofix.yml`.
 
+### Applying codemods on SDK upgrades
+
+A pull request that upgrades `@tailor-platform/sdk`, such as one from Renovate,
+may need the codemods that [`tailor upgrade`](./cli/upgrade.md) runs. Pass
+`--codemod` to have the autofix workflow handle them; without it, the
+workflow runs only `tailor generate`:
+
+```bash
+tailor setup ci autofix --codemod error          # fail the pull request until they are applied
+tailor setup ci autofix --codemod deterministic  # commit what they rewrite
+```
+
+| `--codemod`     | On a pull request that upgrades the SDK                                                                                  | Check fails |
+| --------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------- |
+| `warn`          | Runs `tailor upgrade --dry-run` and reports the files it would rewrite and the changes it leaves for review, as warnings | No          |
+| `error`         | Reports the same as errors, and fails the `tailor-codemod-result` job                                                    | Yes         |
+| `deterministic` | Commits what `tailor upgrade` rewrites together with what `tailor generate` changes, and reports the rest as warnings    | No          |
+
+- **Which upgrade:** for each `--dir`, the workflow upgrades from the SDK
+  version that the lockfile at the repository root resolves on the pull
+  request's base branch to the version the pull request installs. When the
+  base branch has no lockfile of that name, such as when the pull request
+  switches package managers, it upgrades from 2.37.0, the oldest version
+  `tailor setup ci autofix` supports. A pull request that keeps the version,
+  or keeps the SDK linked from a workspace (such as with `workspace:*`), runs
+  no codemod.
+- **Reports:** the files left for you get annotations, and the job summary
+  lists every file, with the migration prompt of each change left for review.
+  Hand the prompt to an AI coding assistant, or follow it yourself.
+- **Required check:** with `error`, require the `tailor-codemod-result` check
+  to block the merge. The workflow still commits what `tailor generate`
+  changes. `tailor-codemod-result` also fails when the `tailor-autofix` job
+  fails or is cancelled, and is skipped, which counts as passing, when that
+  job succeeds with nothing left.
+- **Reviews keep matching:** a change left for review is found by the code it
+  touches, and some codemods ask for a review of the whole app, so a review
+  can still be reported after you finish the migration. With `error`, such a
+  pull request keeps failing until the base branch has the new version.
+- **Workflow files:** GitHub refuses a change to `.github/workflows` from the
+  workflow token or from an App without the Workflows permission, so
+  `deterministic` leaves those files out of the fix commit and reports them.
+  Run `tailor upgrade --from <base version>` and commit them yourself.
+- **Warnings** that `tailor upgrade` prints for code that may still need a
+  manual migration stay warnings with every value.
+- **Lockfile:** bun needs the text `bun.lock`, not `bun.lockb`. A `yarn.lock`
+  does not record which app uses which version, so when the base branch has
+  several SDK versions and the pull request changes them, the workflow fails and
+  you run `tailor upgrade` yourself. Yarn 1 leaves workspace packages out of
+  `yarn.lock`, so the workflow also fails for an app that takes the SDK from a
+  workspace there.
+- **Skipped pull requests:** fork and Dependabot pull requests skip the whole
+  workflow (except fork pull requests with `autofix-ci`), so `error` does not
+  check them, and a skipped check counts as passing.
+
 ## Targeting a workspace
 
 The generated `plan` and `deploy` jobs target a workspace by **id**, read from
@@ -558,9 +624,8 @@ A job that runs `tailor` against the workspace needs the machine-user
 (the `--environment` value, or the workspace name when omitted) as above. A job
 that only uses `app-url`, such as end-to-end tests, does not.
 
-The job is skipped whenever `tailor-preview-deploy` is skipped: for fork pull
-requests, for draft pull requests with `--require ready`, and for unlabeled
-ones with `--require label`.
+The job is skipped whenever `tailor-preview-deploy` is skipped (see
+[Pull requests that get a preview](#pull-requests-that-get-a-preview)).
 
 A preview workspace expires 7 days (`ttl: 7d` on `tailor-preview-deploy`) after
 the last push to its pull request. When a pull request is closed,
@@ -999,8 +1064,10 @@ Before enabling it, note that:
   and validation run, `updatedAt` changes, and executors with
   `recordUpdatedTrigger` fire once per seeded row on every deploy.
 - Every preview deploy deletes the data reviewers added to the preview
-  workspace. That is every push, and with `--require label` also every
-  label added to the pull request, since each one redeploys the preview.
+  workspace. That is every push to a pull request that
+  [gets a preview](#pull-requests-that-get-a-preview), and with
+  `--require label` also every label added to it, since each one redeploys the
+  preview.
 - A seed failure fails the deploy job and its notification, although the deploy
   itself went through.
 - The step shares the deploy job's timeout. IdP users take about a second each.
@@ -1262,10 +1329,10 @@ workflows it reports.
 
 Workflows generated by `setup ci branch`, `setup ci tag`, and `setup ci preview`
 self-audit: each contains a `tailor-drift-check` step that
-runs the check in CI. Preview workflows run it alongside each preview deploy,
-so pull requests that deploy no preview (drafts with `--require ready`, fork
-PRs, and unlabeled PRs with `--require label`) skip the check. A single run audits every workflow
-recorded in `.github/tailor.lock`.
+runs the check in CI. Preview workflows run it in `tailor-preview-deploy`, so
+the check is skipped whenever that job is (see
+[Pull requests that get a preview](#pull-requests-that-get-a-preview)). A single
+run audits every workflow recorded in `.github/tailor.lock`.
 
 Drift findings are advisory by default. Set the repository variable
 `TAILOR_PLATFORM_FAIL_ON_DRIFT` to `true` to make unsuppressed findings fail

package/docs/migration/v2.md

@@ -1612,7 +1612,7 @@ See the SDK testing guide for the full environment setup.
 
 **Migration:** Manual
 
-The name-keyed option types exported from `@tailor-platform/sdk/cli` — `GetWorkflowOptions`, `StartWorkflowOptions`, `ListWorkflowExecutionsOptions`, `GetExecutorOptions`, `TriggerExecutorOptions`, `ListExecutorJobsOptions`, `GetExecutorJobOptions`, `WatchExecutorJobOptions` — are removed in v2, together with the function overloads that accepted them. Pass the workflow or executor definition itself instead: `{ workflow: myWorkflow, invoker: "admin" }` / `{ executor: myExecutor }`, matching the `*TypedOptions` shape that types `arg` and `payload` from the definition. No codemod ships for this migration: rewriting a name string into a definition requires importing the module that defines the workflow or executor, which a source-local transform cannot resolve.
+The name-keyed option types exported from `@tailor-platform/sdk/cli` — `GetWorkflowOptions`, `StartWorkflowOptions`, `ListWorkflowExecutionsOptions`, `GetExecutorOptions`, `TriggerExecutorOptions`, `ListExecutorJobsOptions`, `GetExecutorJobOptions`, `WatchExecutorJobOptions` — are removed in v2, together with the function overloads that accepted them. Pass the workflow or executor definition itself instead: `{ workflow: myWorkflow, invoker: "admin" }` / `{ executor: myExecutor }`, matching the `*TypedOptions` shape that types `arg` from the definition and accepts `payload` only for an executor with an incoming webhook trigger. No codemod ships for this migration: rewriting a name string into a definition requires importing the module that defines the workflow or executor, which a source-local transform cannot resolve.
 
 Before:
 
@@ -1662,8 +1662,10 @@ flagged call site:
    invoker, typed against the machine users declared in tailor.config.ts.
 4. Replace imported option types with the *TypedOptions equivalent
    (e.g. GetWorkflowOptions → GetWorkflowTypedOptions<typeof myWorkflow>).
-   Note that arg (startWorkflow) and payload (triggerExecutor) are now typed
-   from the definition, so a mistyped argument becomes a type error.
+   Note that arg (startWorkflow) is now typed from the definition, so a
+   mistyped argument becomes a type error. Passing payload to
+   triggerExecutor is a type error unless the executor has an incoming
+   webhook trigger.
 
 When the name is only known at runtime (read from argv or an environment
 variable), the CLI command itself — `tailor workflow start <name>` /

package/docs/services/auth.md

@@ -26,6 +26,7 @@ Configure Auth service using `defineAuth()`:
 
 - **One auth per application**: Each application can have exactly one Auth service
 - **Configuration location**: Define in `tailor.config.ts` using `defineAuth()` and reference directly in the config's `auth` field
+- **Referencing another app's auth**: When another app in the same repository defines the auth, reference it with `asExternal()`. See [Referencing another app's Auth with `asExternal()`](../configuration.md#referencing-another-apps-auth-with-asexternal)
 - **`userProfile` and `machineUserAttributes` are mutually exclusive**: Specifying both fails at deploy/generate time with ``Specify either `userProfile` or `machineUserAttributes`, not both.``
 
 ```typescript
@@ -314,6 +315,10 @@ export default createResolver({
 
 Type narrowing is provided by the generated `tailor.d.ts` (the `MachineUserNameRegistry` interface). Run `tailor generate` (or `deploy`) after defining new machine users to refresh it.
 
+`tailor deploy` checks the string `invoker` of every resolver and executor against the machine users of the Auth service it resolves to, and stops with `INVOKER_MACHINE_USER_NOT_FOUND` when the name does not exist. The `invoker` passed to `workflow.start()` is not checked at deploy time. When a config deployed in the same run defines the Auth service, the machine users it lists are the ones checked, because deploy removes the machine users it no longer lists. When the Auth service is only referenced as external, the machine users that exist in the workspace are checked.
+
+When the Auth service is an external one (`auth: { name: "...", external: true }`), the machine users are not in your config, so `tailor.d.ts` cannot narrow the invoker type and any string passes type checking. For resolvers and executors, the deploy-time check is what catches a misspelled name in that case.
+
 ## OAuth 2.0 Clients
 
 Configure OAuth 2.0 clients for third-party applications:

package/docs/services/executor.md

@@ -543,6 +543,8 @@ export default createExecutor({
 
 The webhook URL is public, so verify the signature over the unparsed request body before trusting `body`. `rawBody` is delivered base64-encoded; decode it to the original bytes before computing the signature.
 
+When an executor is triggered manually with [`tailor executor trigger`](../cli/executor.md#executor-trigger) or `triggerExecutor` from `@tailor-platform/sdk/cli`, it receives empty `headers`, even when `--header` is given, and no `rawBody`. To test an executor that reads headers or verifies a signature, send a request to its webhook URL, which [`tailor executor webhook list`](../cli/executor.md#executor-webhook-list) shows.
+
 **With custom response:**
 
 ```typescript

package/docs/services/tailordb/migration.md

@@ -670,7 +670,7 @@ The command performs the following sequence:
 6. Optionally runs an assertion script against the migrated data.
 7. Deletes an automatically-created workspace after success or failure.
 
-Right after creating an automatically-created workspace (step 2), the command records a 24-hour expiry on it. If the run is interrupted before step 7 — for example, a CI job is cancelled or reaches its time limit — the command cannot delete the workspace, so it stays. Once the 24 hours have passed, `tailor workspace prune --expired` (with a location option such as `--organization-root`, `--folder-id`, or `--personal`) deletes it. A workspace given with `--target-workspace-id` is not given an expiry. If recording the expiry fails, the command warns and continues the test.
+Right after creating an automatically-created workspace (step 2), the command records a 24-hour expiry on it. If the run is interrupted before step 7 — for example, a CI job is cancelled or reaches its time limit — the command cannot delete the workspace, so it stays. Once the 24 hours have passed, `tailor workspace prune --expired` (with a location option such as `--organization-root` or `--folder-id`) deletes it. A workspace given with `--target-workspace-id` is not given an expiry. If recording the expiry fails, the command warns and continues the test.
 
 Both the pre-migration and final TailorDB schemas come from committed migration snapshots. Ungenerated changes in the current table definitions are not included in the rehearsal.
 
@@ -846,7 +846,7 @@ To bypass both checks during deploy (not recommended outside of recovery scenari
 tailor deploy --no-schema-check
 ```
 
-With pending migrations, each migration still applies its own table definitions in its [phases](#per-migration-phases), so `migrate.ts` sees the schema it was written for. Local table definitions that differ from the last pending migration are applied after every pending migration has completed, and the deploy lists those tables. With [maintenance mode](#maintenance-mode) on, existing tables stay in it until their local definitions are applied. If one of them cannot be applied, for example a unique constraint on a field whose records hold duplicate values, the deploy fails with `MIGRATION_LOCAL_DEFINITIONS_FAILED`: the migrations stay applied, tables already created for their local definitions remain, and the existing tables keep the definitions of the last migration and leave maintenance mode.
+With pending migrations, each migration still applies its own table definitions in its [phases](#per-migration-phases), so `migrate.ts` sees the schema it was written for. Local table definitions that differ from the last pending migration are applied after every pending migration has completed, and the deploy lists those tables. Tables that the local definitions no longer have are deleted after that in the same deploy, even when no migration removes them. With [maintenance mode](#maintenance-mode) on, existing tables stay in it until their local definitions are applied. If one of them cannot be applied, for example a unique constraint on a field whose records hold duplicate values, the deploy fails with `MIGRATION_LOCAL_DEFINITIONS_FAILED`: the migrations stay applied, tables already created for their local definitions remain, the existing tables keep the definitions of the last migration and leave maintenance mode, and tables that no migration removes are not deleted.
 
 `--no-schema-check` does not bypass the check that the remote migration checkpoint is in the local migration history. See ["Remote migration checkpoint is not in the local migration history" error](#remote-migration-checkpoint-is-not-in-the-local-migration-history-error).
 
@@ -970,7 +970,7 @@ Before a migration's script starts, `tailor deploy` checks that the namespace's
 
 The checkpoint is advanced only after the reversible post-migration schema updates succeed. If the checkpoint write reports an error, the SDK reads it back: a matching value is treated as committed. Any other observed value leaves the post-migration schema unchanged rather than risk rolling back a concurrent deployment; a value beyond the current migration confirms a concurrent deploy, while an older or missing value means the checkpoint must be repaired before retrying, unless the value is the previous checkpoint and the multi-step migration is still recorded as in progress, which the next deploy resumes. If read-back also fails, the SDK likewise leaves the post-migration schema unchanged; verify the remote checkpoint before retrying.
 
-Removed tables are deleted only after the checkpoint is committed. The deploy records with the checkpoint that these deletions are still to run, and clears the record once they finish. If that cleanup fails or the deploy is interrupted, the checkpoint remains at the new migration, and the next deploy finishes the cleanup: it lists the tables that migration removed among the tables to delete, and deletes them and their GQL permissions with their data before it runs any pending migration. `tailor tailordb migration validate` reports them as tables the next deploy deletes. To delete them without deploying, run `tailor tailordb migration sync <N>` with the committed migration as `<N>` (when the cleanup fails, the deploy error's suggestion names the command). A same-named remote table is still reported as remote schema drift when no unfinished cleanup is recorded, for example a table created again after the cleanup completed or one left by an SDK version that did not record the cleanup, and when a later migration adds the table back; delete it with `migration sync <N>` or by hand, and then deploy again. A deploy with `--no-schema-check` does not finish the cleanup of a namespace that has pending migrations, and once those migrations commit, the leftover tables are reported as drift as well.
+Removed tables are deleted only after the checkpoint is committed. The deploy records with the checkpoint that these deletions are still to run, and clears the record once they finish. If that cleanup fails or the deploy is interrupted, the checkpoint remains at the new migration, and the next deploy finishes the cleanup: it lists the tables that migration removed among the tables to delete, and deletes them and their GQL permissions with their data before it runs any pending migration. `tailor tailordb migration validate` reports them as tables the next deploy deletes. To delete them without deploying, run `tailor tailordb migration sync <N>` with the committed migration as `<N>` (when the cleanup fails, the deploy error's suggestion names the command). A same-named remote table is still reported as remote schema drift when no unfinished cleanup is recorded, for example a table created again after the cleanup completed or one left by an SDK version that did not record the cleanup, and when a later migration adds the table back; delete it with `migration sync <N>` or by hand, and then deploy again. A deploy with `--no-schema-check` does not finish the cleanup first: when the namespace has pending migrations, it deletes the leftover tables that the local definitions no longer have after those migrations complete (see [Schema verification](#schema-verification)).
 
 With `--no-schema-check`, local table definitions that the pending migrations do not include are applied after every migration has committed (see [Schema verification](#schema-verification)). If one of them cannot be applied, the deploy fails with `MIGRATION_LOCAL_DEFINITIONS_FAILED`: the migrations stay committed, the existing tables go back to the definitions of the last migration, and tables already created for their local definitions remain. Fix the cause and deploy again. When existing records refuse the definition, for example a unique constraint on a field whose records hold duplicate values, run `tailor tailordb migration generate` to add the change in a migration whose script updates those records, then deploy again; the error's suggestion names the command.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tailor-platform/sdk",
-  "version": "2.38.0",
+  "version": "2.39.0",
   "description": "Tailor Platform SDK - The SDK to work with Tailor Platform",
   "license": "MIT",
   "repository": {
@@ -161,8 +161,8 @@
     "@badgateway/oauth2-client": "3.3.1",
     "@bufbuild/protobuf": "2.16.0",
     "@bufbuild/protovalidate": "1.3.0",
-    "@connectrpc/connect": "2.2.0",
-    "@connectrpc/connect-node": "2.2.0",
+    "@connectrpc/connect": "2.3.0",
+    "@connectrpc/connect-node": "2.3.0",
     "@enlumine/graphql": "0.2.0",
     "@enlumine/sql": "0.2.0",
     "@enlumine/terminal": "0.2.0",
@@ -175,9 +175,9 @@
     "@opentelemetry/exporter-trace-otlp-proto": "0.300.0",
     "@opentelemetry/resources": "3.0.0",
     "@opentelemetry/sdk-trace": "3.0.0",
-    "@opentelemetry/semantic-conventions": "1.43.0",
-    "@oxc-project/types": "0.156.0",
-    "@politty/zod": "0.6.3",
+    "@opentelemetry/semantic-conventions": "1.44.0",
+    "@oxc-project/types": "0.157.0",
+    "@politty/zod": "0.7.1",
     "@secretlint/core": "13.1.0",
     "@secretlint/secretlint-rule-preset-recommend": "13.1.0",
     "@standard-schema/spec": "1.1.0",
@@ -190,19 +190,19 @@
     "find-up-simple": "1.0.1",
     "get-east-asian-width": "1.7.0",
     "get-tsconfig": "4.14.3",
-    "globals": "17.13.0",
+    "globals": "17.14.0",
     "inflection": "3.0.2",
-    "kysely": "0.29.7",
+    "kysely": "0.29.8",
     "lines-db": "0.18.1",
     "mime-types": "3.0.2",
     "open": "11.0.4",
-    "oxc-parser": "0.156.0",
+    "oxc-parser": "0.157.0",
     "p-limit": "7.3.3",
     "pathe": "2.0.3",
     "pgsql-ast-parser": "12.0.2",
     "pkg-types": "2.4.0",
     "rolldown": "1.2.15",
-    "semver": "7.8.5",
+    "semver": "7.8.6",
     "std-env": "4.3.0",
     "temporal-polyfill": "1.0.6",
     "temporal-spec": "1.0.1",
@@ -219,7 +219,7 @@
     "@types/mime-types": "3.0.1",
     "@types/node": "26.6.6",
     "@types/semver": "7.8.0",
-    "@vitest/coverage-v8": "5.0.5",
+    "@vitest/coverage-v8": "5.1.0",
     "eslint-plugin-zod": "5.2.2",
     "graphql": "17.0.2",
     "oxfmt": "0.75.0",
@@ -230,7 +230,7 @@
     "tsrs": "0.16.0-ts7.1.0-dev.20260929",
     "tsx": "4.23.15",
     "typescript": "6.0.3",
-    "vitest": "5.0.5",
+    "vitest": "5.1.0",
     "zinfer": "0.5.2"
   },
   "peerDependencies": {

package/dist/client-CHXix4LD.mjs

@@ -1 +0,0 @@
-import{A as e,C as t,D as n,E as r,F as i,I as a,M as o,N as s,O as c,P as l,S as u,T as d,_ as f,a as p,b as m,c as h,d as g,f as _,g as v,h as y,i as b,j as x,k as S,l as C,m as w,n as T,o as E,p as D,r as O,s as k,t as A,u as j,v as M,w as N,x as P,y as F}from"./client-DOQv-BP8.mjs";import{t as I}from"./user-agent-vdHYF3QL.mjs";export{A as MAX_PAGE_SIZE,T as POOLED_UPLOAD_METHODS,O as RETRY_SAFE_CREATE_METHODS,b as UPLOAD_POOL_MAX_CONNECTIONS,p as closeConnectionPool,E as concurrencyLimitInterceptor,k as createPooledStreamTransport,h as createTransport,C as defaultConsoleBaseUrl,j as defaultPlatformBaseUrl,g as errorHandlingInterceptor,_ as fetchAll,D as fetchAllTolerant,w as fetchMachineUserToken,y as fetchPaged,v as fetchPlatformMachineUserToken,f as fetchUserInfo,M as findAccessTokenSource,F as getConsoleBaseUrl,m as getEffectivePlatformConfig,P as getOAuth2ClientId,u as getOrNull,t as getPlatformBaseUrl,N as hasStaticWebsiteUrlPlaceholder,d as initOAuth2Client,r as initOperatorClient,n as isDefaultPlatform,c as isNotFoundError,S as normalizeBaseUrl,e as parseMethodName,x as registerAccessTokenSource,o as rememberPlatformConfigForToken,s as resolveStaticWebsiteUrls,l as resolveStaticWebsiteUrlsInEnv,i as retryInterceptor,a as staticWebsiteNameFromPlaceholder,I as userAgent};