StartMigrationRequest
Request body for `POST /v1/migrate`. Deliberately has no `project_id` field: the project is always the caller's own authenticated project (from `ProjectAuth`, resolved from the request's auth headers), never a client-supplied value — otherwise a caller could trigger a migration for a project that isn't theirs by simply naming a different id. Has no `max_context_size` either, unlike `MigrationTarget`: that's resolved server-side from infra (`GET /v1/models/{model}?additional_data=true`), the same as `create_vector_store` does - not taken from the client, which would otherwise let a wrong or stale value get written into `embedding_config` at cutover (silently capping chunk size and query length below the target model's real context window).
Request body for POST /v1/migrate. Deliberately has no project_id field: the project is always the caller's own authenticated project (from ProjectAuth, resolved from the request's auth headers), never a client-supplied value — otherwise a caller could trigger a migration for a project that isn't theirs by simply naming a different id. Has no max_context_size either, unlike MigrationTarget: that's resolved server-side from infra (GET /v1/models/{model}?additional_data=true), the same as create_vector_store does - not taken from the client, which would otherwise let a wrong or stale value get written into embedding_config at cutover (silently capping chunk size and query length below the target model's real context window).
| Property | Type | Required | Description |
|---|---|---|---|
model | string | Yes | |
size | integer | Yes | The target embedding model's dense vector dimension. |
sparse | boolean | No | Default: false. |
We use cookies on our website. We use them to ensure proper functioning of the site and, if you agree, for purposes such as analytics, marketing, and targeting ads.
StalledFileDetail
A file that never got a chance to be (re-)attempted this migration. Nightshift processes one file at a time; when another file's permanent failure flips the whole migration to `failed` first, any file whose message hadn't been picked up yet is skipped without ever being attempted (see `reembed_file_for_migration`'s early exit when the migration is no longer `migrating` - required to avoid a duplicate-processing race against a concurrent retry). It stays `pending` forever unless surfaced explicitly here; a `retry` re-dispatches it same as any other non-completed file.
StatusOk
Next Page