@alien_intelligence/data-api-client 2.3.1 → 2.5.0

package/dist/src/apis/AdminApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/AdminApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/DatasetsApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -121,7 +121,7 @@ export interface DatasetsApiInterface {
      */
     listDatasetsApiV1DatasetsGet(requestParameters: ListDatasetsApiV1DatasetsGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<DatasetListResponse>;
     /**
-     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, as fresh as the last write of it.
+     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, rewritten whole from the row by the keyword-index worker, which this queues.
      * @summary Sync Dataset Stats
      * @param {number} datasetId
      * @param {*} [options] Override http request option.
@@ -130,12 +130,12 @@ export interface DatasetsApiInterface {
      */
     syncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPostRaw(requestParameters: SyncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<void>>;
     /**
-     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, as fresh as the last write of it.
+     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, rewritten whole from the row by the keyword-index worker, which this queues.
      * Sync Dataset Stats
      */
     syncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPost(requestParameters: SyncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<void>;
     /**
-     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.
+     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.  Its datasets-index document is queued for the keyword-index worker with the update. A new dataset_type also queues every entry of the dataset: each entry document carries it, and a filter on it would keep finding the entries under the old one.
      * @summary Update Dataset
      * @param {number} datasetId
      * @param {DatasetUpdateRequest} datasetUpdateRequest
@@ -145,12 +145,12 @@ export interface DatasetsApiInterface {
      */
     updateDatasetApiV1DatasetsDatasetIdPatchRaw(requestParameters: UpdateDatasetApiV1DatasetsDatasetIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Dataset>>;
     /**
-     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.
+     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.  Its datasets-index document is queued for the keyword-index worker with the update. A new dataset_type also queues every entry of the dataset: each entry document carries it, and a filter on it would keep finding the entries under the old one.
      * Update Dataset
      */
     updateDatasetApiV1DatasetsDatasetIdPatch(requestParameters: UpdateDatasetApiV1DatasetsDatasetIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Dataset>;
     /**
-     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").
+     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").  The new schema\'s fields are registered with the entries index only once the row is committed and its lock released: a settings update waits behind the whole shared Meilisearch queue, and the dataset row stayed locked for that long.
      * @summary Update Dataset Schema
      * @param {number} datasetId
      * @param {DatasetUpdateSchemaRequest} datasetUpdateSchemaRequest
@@ -160,7 +160,7 @@ export interface DatasetsApiInterface {
      */
     updateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatchRaw(requestParameters: UpdateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Dataset>>;
     /**
-     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").
+     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").  The new schema\'s fields are registered with the entries index only once the row is committed and its lock released: a settings update waits behind the whole shared Meilisearch queue, and the dataset row stayed locked for that long.
      * Update Dataset Schema
      */
     updateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatch(requestParameters: UpdateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Dataset>;
@@ -220,32 +220,32 @@ export declare class DatasetsApi extends runtime.BaseAPI implements DatasetsApiI
      */
     listDatasetsApiV1DatasetsGet(requestParameters?: ListDatasetsApiV1DatasetsGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<DatasetListResponse>;
     /**
-     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, as fresh as the last write of it.
+     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, rewritten whole from the row by the keyword-index worker, which this queues.
      * Sync Dataset Stats
      */
     syncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPostRaw(requestParameters: SyncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<void>>;
     /**
-     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, as fresh as the last write of it.
+     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, rewritten whole from the row by the keyword-index worker, which this queues.
      * Sync Dataset Stats
      */
     syncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPost(requestParameters: SyncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<void>;
     /**
-     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.
+     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.  Its datasets-index document is queued for the keyword-index worker with the update. A new dataset_type also queues every entry of the dataset: each entry document carries it, and a filter on it would keep finding the entries under the old one.
      * Update Dataset
      */
     updateDatasetApiV1DatasetsDatasetIdPatchRaw(requestParameters: UpdateDatasetApiV1DatasetsDatasetIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Dataset>>;
     /**
-     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.
+     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.  Its datasets-index document is queued for the keyword-index worker with the update. A new dataset_type also queues every entry of the dataset: each entry document carries it, and a filter on it would keep finding the entries under the old one.
      * Update Dataset
      */
     updateDatasetApiV1DatasetsDatasetIdPatch(requestParameters: UpdateDatasetApiV1DatasetsDatasetIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Dataset>;
     /**
-     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").
+     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").  The new schema\'s fields are registered with the entries index only once the row is committed and its lock released: a settings update waits behind the whole shared Meilisearch queue, and the dataset row stayed locked for that long.
      * Update Dataset Schema
      */
     updateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatchRaw(requestParameters: UpdateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Dataset>>;
     /**
-     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").
+     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").  The new schema\'s fields are registered with the entries index only once the row is committed and its lock released: a settings update waits behind the whole shared Meilisearch queue, and the dataset row stayed locked for that long.
      * Update Dataset Schema
      */
     updateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatch(requestParameters: UpdateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Dataset>;

package/dist/src/apis/DatasetsApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -194,7 +194,7 @@ class DatasetsApi extends runtime.BaseAPI {
         return await response.value();
     }
     /**
-     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, as fresh as the last write of it.
+     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, rewritten whole from the row by the keyword-index worker, which this queues.
      * Sync Dataset Stats
      */
     async syncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPostRaw(requestParameters, initOverrides) {
@@ -212,14 +212,14 @@ class DatasetsApi extends runtime.BaseAPI {
         return new runtime.VoidApiResponse(response);
     }
     /**
-     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, as fresh as the last write of it.
+     * Copy the dataset\'s entry count and size to its Meilisearch datasets document.  The database keeps them current itself (a trigger on `entries`); the search document holds a copy, rewritten whole from the row by the keyword-index worker, which this queues.
      * Sync Dataset Stats
      */
     async syncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPost(requestParameters, initOverrides) {
         await this.syncDatasetStatsApiV1DatasetsDatasetIdSyncStatsPostRaw(requestParameters, initOverrides);
     }
     /**
-     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.
+     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.  Its datasets-index document is queued for the keyword-index worker with the update. A new dataset_type also queues every entry of the dataset: each entry document carries it, and a filter on it would keep finding the entries under the old one.
      * Update Dataset
      */
     async updateDatasetApiV1DatasetsDatasetIdPatchRaw(requestParameters, initOverrides) {
@@ -242,7 +242,7 @@ class DatasetsApi extends runtime.BaseAPI {
         return new runtime.JSONApiResponse(response, (jsonValue) => (0, index_1.DatasetFromJSON)(jsonValue));
     }
     /**
-     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.
+     * Partially update dataset metadata.  Accepts any combination of: name, slug, description, dataset_type. Fields not provided are left unchanged. Bumps the dataset version atomically.  Its datasets-index document is queued for the keyword-index worker with the update. A new dataset_type also queues every entry of the dataset: each entry document carries it, and a filter on it would keep finding the entries under the old one.
      * Update Dataset
      */
     async updateDatasetApiV1DatasetsDatasetIdPatch(requestParameters, initOverrides) {
@@ -250,7 +250,7 @@ class DatasetsApi extends runtime.BaseAPI {
         return await response.value();
     }
     /**
-     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").
+     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").  The new schema\'s fields are registered with the entries index only once the row is committed and its lock released: a settings update waits behind the whole shared Meilisearch queue, and the dataset row stayed locked for that long.
      * Update Dataset Schema
      */
     async updateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatchRaw(requestParameters, initOverrides) {
@@ -273,7 +273,7 @@ class DatasetsApi extends runtime.BaseAPI {
         return new runtime.JSONApiResponse(response, (jsonValue) => (0, index_1.DatasetFromJSON)(jsonValue));
     }
     /**
-     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").
+     * Update dataset schema definition.  Called when schema evolves to a new version. The current_schema_version is auto-bumped by incrementing the integer suffix of the current version (e.g., \"v3\" -> \"v4\").  The new schema\'s fields are registered with the entries index only once the row is committed and its lock released: a settings update waits behind the whole shared Meilisearch queue, and the dataset row stayed locked for that long.
      * Update Dataset Schema
      */
     async updateDatasetSchemaApiV1DatasetsDatasetIdSchemaPatch(requestParameters, initOverrides) {

package/dist/src/apis/DefaultApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/DefaultApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/EmbeddingsApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/EmbeddingsApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/EntriesApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -193,7 +193,7 @@ export interface EntriesApiInterface {
      */
     getEntryApiV1EntriesEntryIdGet(requestParameters: GetEntryApiV1EntriesEntryIdGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Entry>;
     /**
-     * Get processed content for a single entry
+     * The entry\'s processed content. `text` is always a string when present: the canonical text every offset this API returns indexes into (segment `char_start`/`char_end`, keyword-search snippet `context.offset`). Content stored with `text` as a list of chunks is served with the chunks joined by one space.
      * @summary Get Entry Content
      * @param {number} entryId
      * @param {*} [options] Override http request option.
@@ -204,7 +204,7 @@ export interface EntriesApiInterface {
         [key: string]: any;
     }>>;
     /**
-     * Get processed content for a single entry
+     * The entry\'s processed content. `text` is always a string when present: the canonical text every offset this API returns indexes into (segment `char_start`/`char_end`, keyword-search snippet `context.offset`). Content stored with `text` as a list of chunks is served with the chunks joined by one space.
      * Get Entry Content
      */
     getEntryContentApiV1EntriesEntryIdContentGet(requestParameters: GetEntryContentApiV1EntriesEntryIdContentGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<{
@@ -297,7 +297,7 @@ export interface EntriesApiInterface {
      */
     moveEntryApiV1EntriesEntryIdMovePost(requestParameters: MoveEntryApiV1EntriesEntryIdMovePostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<MoveEntryResponse>;
     /**
-     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, its segment documents, its entries-index document, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
+     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched. Its keyword-index documents are removed by the keyword-index worker, from a reindex queued in the same transaction.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  A reset that deleted anything (a manifest section, an object under `processed/` or `processing/`, a vector point) bumps the version and logs the change, even when the manifest held none of it: a writer that stored objects for the entry outside its lock, as batch ingest does, checks the version under the lock and must see that they went.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
      * @summary Reset Entry Processing
      * @param {number} entryId
      * @param {*} [options] Override http request option.
@@ -306,12 +306,12 @@ export interface EntriesApiInterface {
      */
     resetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRaw(requestParameters: ResetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ProcessingResetResponse>>;
     /**
-     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, its segment documents, its entries-index document, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
+     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched. Its keyword-index documents are removed by the keyword-index worker, from a reindex queued in the same transaction.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  A reset that deleted anything (a manifest section, an object under `processed/` or `processing/`, a vector point) bumps the version and logs the change, even when the manifest held none of it: a writer that stored objects for the entry outside its lock, as batch ingest does, checks the version under the lock and must see that they went.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
      * Reset Entry Processing
      */
     resetEntryProcessingApiV1EntriesEntryIdProcessingResetPost(requestParameters: ResetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ProcessingResetResponse>;
     /**
-     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as three short transactions with the external calls between them: read the entry, store the objects, write the row and commit, index, record what the index holds. `_commit_processed_row` and `_index_processed_entry` say how each stays consistent with what was done while no lock was held.
+     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as two short transactions with the object-storage write between them: read the entry, store the objects, then write the row and queue its keyword indexing, and commit. `_commit_processed_row` says how the row stays consistent with what was done while no lock was held.  Never writes Meilisearch. The entry is searchable by keyword once the keyword-index worker (`SearchIndexRepairService`) has written it, in bulk with every other entry due: within its interval while Meilisearch keeps up, later when the shared queue is backed up. `GET /health` and every keyword search report that lag.
      * @summary Save Processed Content
      * @param {number} entryId
      * @param {SaveProcessedContentRequest} saveProcessedContentRequest
@@ -321,7 +321,7 @@ export interface EntriesApiInterface {
      */
     saveProcessedContentApiV1EntriesEntryIdProcessedPostRaw(requestParameters: SaveProcessedContentApiV1EntriesEntryIdProcessedPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SaveProcessedContentResponse>>;
     /**
-     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as three short transactions with the external calls between them: read the entry, store the objects, write the row and commit, index, record what the index holds. `_commit_processed_row` and `_index_processed_entry` say how each stays consistent with what was done while no lock was held.
+     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as two short transactions with the object-storage write between them: read the entry, store the objects, then write the row and queue its keyword indexing, and commit. `_commit_processed_row` says how the row stays consistent with what was done while no lock was held.  Never writes Meilisearch. The entry is searchable by keyword once the keyword-index worker (`SearchIndexRepairService`) has written it, in bulk with every other entry due: within its interval while Meilisearch keeps up, later when the shared queue is backed up. `GET /health` and every keyword search report that lag.
      * Save Processed Content
      */
     saveProcessedContentApiV1EntriesEntryIdProcessedPost(requestParameters: SaveProcessedContentApiV1EntriesEntryIdProcessedPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SaveProcessedContentResponse>;
@@ -340,7 +340,7 @@ export interface EntriesApiInterface {
      */
     triggerPipelineApiV1EntriesEntryIdTriggerPipelinePost(requestParameters: TriggerPipelineApiV1EntriesEntryIdTriggerPipelinePostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<any>;
     /**
-     * Update entry metadata.  Allows updating name, description, status, and metadata fields.
+     * Update entry metadata.  Allows updating name, description, status, and metadata fields. Every one of them is in the entry\'s search documents, so the update queues the entry\'s keyword re-index in the same transaction; the keyword-index worker writes it in bulk.
      * @summary Update Entry
      * @param {number} entryId
      * @param {EntryUpdateRequest} entryUpdateRequest
@@ -350,7 +350,7 @@ export interface EntriesApiInterface {
      */
     updateEntryApiV1EntriesEntryIdPatchRaw(requestParameters: UpdateEntryApiV1EntriesEntryIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Entry>>;
     /**
-     * Update entry metadata.  Allows updating name, description, status, and metadata fields.
+     * Update entry metadata.  Allows updating name, description, status, and metadata fields. Every one of them is in the entry\'s search documents, so the update queues the entry\'s keyword re-index in the same transaction; the keyword-index worker writes it in bulk.
      * Update Entry
      */
     updateEntryApiV1EntriesEntryIdPatch(requestParameters: UpdateEntryApiV1EntriesEntryIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Entry>;
@@ -450,14 +450,14 @@ export declare class EntriesApi extends runtime.BaseAPI implements EntriesApiInt
      */
     getEntryApiV1EntriesEntryIdGet(requestParameters: GetEntryApiV1EntriesEntryIdGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Entry>;
     /**
-     * Get processed content for a single entry
+     * The entry\'s processed content. `text` is always a string when present: the canonical text every offset this API returns indexes into (segment `char_start`/`char_end`, keyword-search snippet `context.offset`). Content stored with `text` as a list of chunks is served with the chunks joined by one space.
      * Get Entry Content
      */
     getEntryContentApiV1EntriesEntryIdContentGetRaw(requestParameters: GetEntryContentApiV1EntriesEntryIdContentGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<{
         [key: string]: any;
     }>>;
     /**
-     * Get processed content for a single entry
+     * The entry\'s processed content. `text` is always a string when present: the canonical text every offset this API returns indexes into (segment `char_start`/`char_end`, keyword-search snippet `context.offset`). Content stored with `text` as a list of chunks is served with the chunks joined by one space.
      * Get Entry Content
      */
     getEntryContentApiV1EntriesEntryIdContentGet(requestParameters: GetEntryContentApiV1EntriesEntryIdContentGetRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<{
@@ -522,22 +522,22 @@ export declare class EntriesApi extends runtime.BaseAPI implements EntriesApiInt
      */
     moveEntryApiV1EntriesEntryIdMovePost(requestParameters: MoveEntryApiV1EntriesEntryIdMovePostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<MoveEntryResponse>;
     /**
-     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, its segment documents, its entries-index document, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
+     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched. Its keyword-index documents are removed by the keyword-index worker, from a reindex queued in the same transaction.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  A reset that deleted anything (a manifest section, an object under `processed/` or `processing/`, a vector point) bumps the version and logs the change, even when the manifest held none of it: a writer that stored objects for the entry outside its lock, as batch ingest does, checks the version under the lock and must see that they went.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
      * Reset Entry Processing
      */
     resetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRaw(requestParameters: ResetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ProcessingResetResponse>>;
     /**
-     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, its segment documents, its entries-index document, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
+     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched. Its keyword-index documents are removed by the keyword-index worker, from a reindex queued in the same transaction.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  A reset that deleted anything (a manifest section, an object under `processed/` or `processing/`, a vector point) bumps the version and logs the change, even when the manifest held none of it: a writer that stored objects for the entry outside its lock, as batch ingest does, checks the version under the lock and must see that they went.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
      * Reset Entry Processing
      */
     resetEntryProcessingApiV1EntriesEntryIdProcessingResetPost(requestParameters: ResetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ProcessingResetResponse>;
     /**
-     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as three short transactions with the external calls between them: read the entry, store the objects, write the row and commit, index, record what the index holds. `_commit_processed_row` and `_index_processed_entry` say how each stays consistent with what was done while no lock was held.
+     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as two short transactions with the object-storage write between them: read the entry, store the objects, then write the row and queue its keyword indexing, and commit. `_commit_processed_row` says how the row stays consistent with what was done while no lock was held.  Never writes Meilisearch. The entry is searchable by keyword once the keyword-index worker (`SearchIndexRepairService`) has written it, in bulk with every other entry due: within its interval while Meilisearch keeps up, later when the shared queue is backed up. `GET /health` and every keyword search report that lag.
      * Save Processed Content
      */
     saveProcessedContentApiV1EntriesEntryIdProcessedPostRaw(requestParameters: SaveProcessedContentApiV1EntriesEntryIdProcessedPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SaveProcessedContentResponse>>;
     /**
-     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as three short transactions with the external calls between them: read the entry, store the objects, write the row and commit, index, record what the index holds. `_commit_processed_row` and `_index_processed_entry` say how each stays consistent with what was done while no lock was held.
+     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as two short transactions with the object-storage write between them: read the entry, store the objects, then write the row and queue its keyword indexing, and commit. `_commit_processed_row` says how the row stays consistent with what was done while no lock was held.  Never writes Meilisearch. The entry is searchable by keyword once the keyword-index worker (`SearchIndexRepairService`) has written it, in bulk with every other entry due: within its interval while Meilisearch keeps up, later when the shared queue is backed up. `GET /health` and every keyword search report that lag.
      * Save Processed Content
      */
     saveProcessedContentApiV1EntriesEntryIdProcessedPost(requestParameters: SaveProcessedContentApiV1EntriesEntryIdProcessedPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SaveProcessedContentResponse>;
@@ -552,12 +552,12 @@ export declare class EntriesApi extends runtime.BaseAPI implements EntriesApiInt
      */
     triggerPipelineApiV1EntriesEntryIdTriggerPipelinePost(requestParameters: TriggerPipelineApiV1EntriesEntryIdTriggerPipelinePostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<any>;
     /**
-     * Update entry metadata.  Allows updating name, description, status, and metadata fields.
+     * Update entry metadata.  Allows updating name, description, status, and metadata fields. Every one of them is in the entry\'s search documents, so the update queues the entry\'s keyword re-index in the same transaction; the keyword-index worker writes it in bulk.
      * Update Entry
      */
     updateEntryApiV1EntriesEntryIdPatchRaw(requestParameters: UpdateEntryApiV1EntriesEntryIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Entry>>;
     /**
-     * Update entry metadata.  Allows updating name, description, status, and metadata fields.
+     * Update entry metadata.  Allows updating name, description, status, and metadata fields. Every one of them is in the entry\'s search documents, so the update queues the entry\'s keyword re-index in the same transaction; the keyword-index worker writes it in bulk.
      * Update Entry
      */
     updateEntryApiV1EntriesEntryIdPatch(requestParameters: UpdateEntryApiV1EntriesEntryIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Entry>;

package/dist/src/apis/EntriesApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -272,7 +272,7 @@ class EntriesApi extends runtime.BaseAPI {
         return await response.value();
     }
     /**
-     * Get processed content for a single entry
+     * The entry\'s processed content. `text` is always a string when present: the canonical text every offset this API returns indexes into (segment `char_start`/`char_end`, keyword-search snippet `context.offset`). Content stored with `text` as a list of chunks is served with the chunks joined by one space.
      * Get Entry Content
      */
     async getEntryContentApiV1EntriesEntryIdContentGetRaw(requestParameters, initOverrides) {
@@ -290,7 +290,7 @@ class EntriesApi extends runtime.BaseAPI {
         return new runtime.JSONApiResponse(response);
     }
     /**
-     * Get processed content for a single entry
+     * The entry\'s processed content. `text` is always a string when present: the canonical text every offset this API returns indexes into (segment `char_start`/`char_end`, keyword-search snippet `context.offset`). Content stored with `text` as a list of chunks is served with the chunks joined by one space.
      * Get Entry Content
      */
     async getEntryContentApiV1EntriesEntryIdContentGet(requestParameters, initOverrides) {
@@ -464,7 +464,7 @@ class EntriesApi extends runtime.BaseAPI {
         return await response.value();
     }
     /**
-     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, its segment documents, its entries-index document, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
+     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched. Its keyword-index documents are removed by the keyword-index worker, from a reindex queued in the same transaction.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  A reset that deleted anything (a manifest section, an object under `processed/` or `processing/`, a vector point) bumps the version and logs the change, even when the manifest held none of it: a writer that stored objects for the entry outside its lock, as batch ingest does, checks the version under the lock and must see that they went.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
      * Reset Entry Processing
      */
     async resetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRaw(requestParameters, initOverrides) {
@@ -482,7 +482,7 @@ class EntriesApi extends runtime.BaseAPI {
         return new runtime.JSONApiResponse(response, (jsonValue) => (0, index_1.ProcessingResetResponseFromJSON)(jsonValue));
     }
     /**
-     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, its segment documents, its entries-index document, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
+     * Remove everything a processing run derived from an entry, so it can be processed again.  Called by the backend before it re-drives a processing job whose previous attempt failed on infrastructure (a killed worker, a lost heartbeat). Clears, in order: the entry\'s vector points, the objects under its `processed/` and `processing/` prefixes plus every key those two manifest sections registered, and finally the two sections themselves. `original` is never touched. Its keyword-index documents are removed by the keyword-index worker, from a reindex queued in the same transaction.  **The status is never changed.** The processing pool never writes `processing`, and `uploaded` is already the right status for a queued re-run; a reset that rewrote it would race the backend\'s own status bookkeeping. For the same reason a `processed` entry is refused rather than reset: clearing its output under a status that says it is complete would leave a document claiming content it no longer has.  A reset that deleted anything (a manifest section, an object under `processed/` or `processing/`, a vector point) bumps the version and logs the change, even when the manifest held none of it: a writer that stored objects for the entry outside its lock, as batch ingest does, checks the version under the lock and must see that they went.  Idempotent: resetting an entry with nothing derived is a 200 with zero counts and `changed=false`, and does not bump the version. A failure at any store is a 503 that leaves the row untouched, and retrying converges.
      * Reset Entry Processing
      */
     async resetEntryProcessingApiV1EntriesEntryIdProcessingResetPost(requestParameters, initOverrides) {
@@ -490,7 +490,7 @@ class EntriesApi extends runtime.BaseAPI {
         return await response.value();
     }
     /**
-     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as three short transactions with the external calls between them: read the entry, store the objects, write the row and commit, index, record what the index holds. `_commit_processed_row` and `_index_processed_entry` say how each stays consistent with what was done while no lock was held.
+     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as two short transactions with the object-storage write between them: read the entry, store the objects, then write the row and queue its keyword indexing, and commit. `_commit_processed_row` says how the row stays consistent with what was done while no lock was held.  Never writes Meilisearch. The entry is searchable by keyword once the keyword-index worker (`SearchIndexRepairService`) has written it, in bulk with every other entry due: within its interval while Meilisearch keeps up, later when the shared queue is backed up. `GET /health` and every keyword search report that lag.
      * Save Processed Content
      */
     async saveProcessedContentApiV1EntriesEntryIdProcessedPostRaw(requestParameters, initOverrides) {
@@ -513,7 +513,7 @@ class EntriesApi extends runtime.BaseAPI {
         return new runtime.JSONApiResponse(response, (jsonValue) => (0, index_1.SaveProcessedContentResponseFromJSON)(jsonValue));
     }
     /**
-     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as three short transactions with the external calls between them: read the entry, store the objects, write the row and commit, index, record what the index holds. `_commit_processed_row` and `_index_processed_entry` say how each stays consistent with what was done while no lock was held.
+     * Save processed content for an entry.  Called by workers/pipelines after processing.  Safe to repeat. The whole `processed` section is rewritten, so a re-run replaces the previous segmentation instead of merging with it - a second pass that yields fewer segments leaves none of the first pass\'s behind. That matters beyond tidiness: the backend reaper and this cluster\'s own staleness detection can both fire for the same entry, and re-ingest being idempotent is what makes double-triggering harmless.  Holds a database connection only while it reads or writes the database. The tenant database sits behind PgBouncer in transaction mode, where an open transaction owns one of the tenant\'s few server connections; this route used to keep one open from its first read to after the response, across the object-storage write and the Meilisearch indexing - on 2026-10-28 a bulk ingest kept ~39 of them idle in transaction at once, for seconds each. It now runs as two short transactions with the object-storage write between them: read the entry, store the objects, then write the row and queue its keyword indexing, and commit. `_commit_processed_row` says how the row stays consistent with what was done while no lock was held.  Never writes Meilisearch. The entry is searchable by keyword once the keyword-index worker (`SearchIndexRepairService`) has written it, in bulk with every other entry due: within its interval while Meilisearch keeps up, later when the shared queue is backed up. `GET /health` and every keyword search report that lag.
      * Save Processed Content
      */
     async saveProcessedContentApiV1EntriesEntryIdProcessedPost(requestParameters, initOverrides) {
@@ -552,7 +552,7 @@ class EntriesApi extends runtime.BaseAPI {
         return await response.value();
     }
     /**
-     * Update entry metadata.  Allows updating name, description, status, and metadata fields.
+     * Update entry metadata.  Allows updating name, description, status, and metadata fields. Every one of them is in the entry\'s search documents, so the update queues the entry\'s keyword re-index in the same transaction; the keyword-index worker writes it in bulk.
      * Update Entry
      */
     async updateEntryApiV1EntriesEntryIdPatchRaw(requestParameters, initOverrides) {
@@ -575,7 +575,7 @@ class EntriesApi extends runtime.BaseAPI {
         return new runtime.JSONApiResponse(response, (jsonValue) => (0, index_1.EntryFromJSON)(jsonValue));
     }
     /**
-     * Update entry metadata.  Allows updating name, description, status, and metadata fields.
+     * Update entry metadata.  Allows updating name, description, status, and metadata fields. Every one of them is in the entry\'s search documents, so the update queues the entry\'s keyword re-index in the same transaction; the keyword-index worker writes it in bulk.
      * Update Entry
      */
     async updateEntryApiV1EntriesEntryIdPatch(requestParameters, initOverrides) {

package/dist/src/apis/HealthApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/HealthApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/PipelinesApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/PipelinesApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/SearchApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/SearchApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/SyncApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/SyncApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/WebhooksApi.d.ts

@@ -2,7 +2,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/src/apis/WebhooksApi.js

@@ -5,7 +5,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.3.1
+ * The version of the OpenAPI document: 2.5.0
  *
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).