@alien_intelligence/data-api-client 2.2.1 → 2.3.2

package/src/src/apis/EntriesApi.ts

@@ -4,7 +4,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.2.1
+ * The version of the OpenAPI document: 2.3.2
  * 
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -385,7 +385,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.  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.
@@ -395,13 +395,13 @@ 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.  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 
@@ -412,7 +412,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>;
@@ -434,7 +434,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 
@@ -445,7 +445,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>;
@@ -1022,7 +1022,7 @@ export class EntriesApi extends runtime.BaseAPI implements EntriesApiInterface {
     }
 
     /**
-     * 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.  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: ResetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ProcessingResetResponse>> {
@@ -1048,7 +1048,7 @@ export class EntriesApi extends runtime.BaseAPI implements EntriesApiInterface {
     }
 
     /**
-     * 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.  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: ResetEntryProcessingApiV1EntriesEntryIdProcessingResetPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ProcessingResetResponse> {
@@ -1057,7 +1057,7 @@ export class EntriesApi extends runtime.BaseAPI implements EntriesApiInterface {
     }
 
     /**
-     * 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: SaveProcessedContentApiV1EntriesEntryIdProcessedPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SaveProcessedContentResponse>> {
@@ -1093,7 +1093,7 @@ export class EntriesApi extends runtime.BaseAPI implements EntriesApiInterface {
     }
 
     /**
-     * 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: SaveProcessedContentApiV1EntriesEntryIdProcessedPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SaveProcessedContentResponse> {
@@ -1141,7 +1141,7 @@ export class EntriesApi extends runtime.BaseAPI implements EntriesApiInterface {
     }
 
     /**
-     * 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: UpdateEntryApiV1EntriesEntryIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Entry>> {
@@ -1177,7 +1177,7 @@ export class EntriesApi extends runtime.BaseAPI implements EntriesApiInterface {
     }
 
     /**
-     * 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: UpdateEntryApiV1EntriesEntryIdPatchRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Entry> {

package/src/src/apis/HealthApi.ts

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

package/src/src/apis/PipelinesApi.ts

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

package/src/src/apis/SearchApi.ts

@@ -4,7 +4,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.2.1
+ * The version of the OpenAPI document: 2.3.2
  * 
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -58,7 +58,7 @@ export interface VectorSearchEntriesApiV1VectorEntriesPostRequest {
  */
 export interface SearchApiInterface {
     /**
-     * **Keyword search endpoint** - Search documents using Meilisearch for full-text and faceted search.      This endpoint provides fast keyword search with typo tolerance, relevance ranking,     and powerful filtering capabilities.      **Features**:     - Full-text search across title, description, abstract, text content     - Typo tolerance (finds \"machnie\" when searching for \"machine\")     - Relevance ranking based on TF-IDF and proximity     - Faceted filtering by dataset, status, MIME type, tags     - Sorting by date, size, relevance     - Highlighted search results      **Flow**:     1. Query is sent to Meilisearch     2. Full-text search across indexed fields     3. Filters are applied (dataset_id, status, etc.)     4. Results are ranked and highlighted     5. Metadata is returned (no S3 fetching)      **Performance**: Typically < 50ms for most queries      **Use cases**:     - Keyword-based document discovery     - Filtering by metadata (tags, type, dataset)     - Search with typo tolerance     - Faceted search interfaces     - Finding documents by title, author, abstract
+     * **Keyword search endpoint** - Search documents using Meilisearch for full-text and faceted search.      This endpoint provides fast keyword search with typo tolerance, relevance ranking,     and powerful filtering capabilities.      **Features**:     - Full-text search across title, description, abstract, text content     - Typo tolerance (finds \"machnie\" when searching for \"machine\")     - Relevance ranking based on TF-IDF and proximity     - Faceted filtering by dataset, status, MIME type, tags     - Sorting by date, size, relevance     - Highlighted search results      **Flow**:     1. Query is sent to Meilisearch     2. Full-text search across indexed fields     3. Filters are applied (dataset_id, status, etc.)     4. Results are ranked and highlighted     5. Metadata is returned (no S3 fetching)      **Performance**: Typically < 50ms for most queries      **503 Service Unavailable** with `Retry-After`: the index this search needs is not     ready, because its filterable and sortable attributes are not yet confirmed applied     by Meilisearch, for example right after the index was created.     Retry after the given number of seconds.      **Use cases**:     - Keyword-based document discovery     - Filtering by metadata (tags, type, dataset)     - Search with typo tolerance     - Faceted search interfaces     - Finding documents by title, author, abstract
      * @summary Keyword/faceted search for documents
      * @param {KeywordSearchRequest} keywordSearchRequest 
      * @param {*} [options] Override http request option.
@@ -68,7 +68,7 @@ export interface SearchApiInterface {
     keywordSearchApiV1SearchPostRaw(requestParameters: KeywordSearchApiV1SearchPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<KeywordSearchResponse>>;
 
     /**
-     * **Keyword search endpoint** - Search documents using Meilisearch for full-text and faceted search.      This endpoint provides fast keyword search with typo tolerance, relevance ranking,     and powerful filtering capabilities.      **Features**:     - Full-text search across title, description, abstract, text content     - Typo tolerance (finds \"machnie\" when searching for \"machine\")     - Relevance ranking based on TF-IDF and proximity     - Faceted filtering by dataset, status, MIME type, tags     - Sorting by date, size, relevance     - Highlighted search results      **Flow**:     1. Query is sent to Meilisearch     2. Full-text search across indexed fields     3. Filters are applied (dataset_id, status, etc.)     4. Results are ranked and highlighted     5. Metadata is returned (no S3 fetching)      **Performance**: Typically < 50ms for most queries      **Use cases**:     - Keyword-based document discovery     - Filtering by metadata (tags, type, dataset)     - Search with typo tolerance     - Faceted search interfaces     - Finding documents by title, author, abstract
+     * **Keyword search endpoint** - Search documents using Meilisearch for full-text and faceted search.      This endpoint provides fast keyword search with typo tolerance, relevance ranking,     and powerful filtering capabilities.      **Features**:     - Full-text search across title, description, abstract, text content     - Typo tolerance (finds \"machnie\" when searching for \"machine\")     - Relevance ranking based on TF-IDF and proximity     - Faceted filtering by dataset, status, MIME type, tags     - Sorting by date, size, relevance     - Highlighted search results      **Flow**:     1. Query is sent to Meilisearch     2. Full-text search across indexed fields     3. Filters are applied (dataset_id, status, etc.)     4. Results are ranked and highlighted     5. Metadata is returned (no S3 fetching)      **Performance**: Typically < 50ms for most queries      **503 Service Unavailable** with `Retry-After`: the index this search needs is not     ready, because its filterable and sortable attributes are not yet confirmed applied     by Meilisearch, for example right after the index was created.     Retry after the given number of seconds.      **Use cases**:     - Keyword-based document discovery     - Filtering by metadata (tags, type, dataset)     - Search with typo tolerance     - Faceted search interfaces     - Finding documents by title, author, abstract
      * Keyword/faceted search for documents
      */
     keywordSearchApiV1SearchPost(requestParameters: KeywordSearchApiV1SearchPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<KeywordSearchResponse>;
@@ -114,7 +114,7 @@ export interface SearchApiInterface {
 export class SearchApi extends runtime.BaseAPI implements SearchApiInterface {
 
     /**
-     * **Keyword search endpoint** - Search documents using Meilisearch for full-text and faceted search.      This endpoint provides fast keyword search with typo tolerance, relevance ranking,     and powerful filtering capabilities.      **Features**:     - Full-text search across title, description, abstract, text content     - Typo tolerance (finds \"machnie\" when searching for \"machine\")     - Relevance ranking based on TF-IDF and proximity     - Faceted filtering by dataset, status, MIME type, tags     - Sorting by date, size, relevance     - Highlighted search results      **Flow**:     1. Query is sent to Meilisearch     2. Full-text search across indexed fields     3. Filters are applied (dataset_id, status, etc.)     4. Results are ranked and highlighted     5. Metadata is returned (no S3 fetching)      **Performance**: Typically < 50ms for most queries      **Use cases**:     - Keyword-based document discovery     - Filtering by metadata (tags, type, dataset)     - Search with typo tolerance     - Faceted search interfaces     - Finding documents by title, author, abstract
+     * **Keyword search endpoint** - Search documents using Meilisearch for full-text and faceted search.      This endpoint provides fast keyword search with typo tolerance, relevance ranking,     and powerful filtering capabilities.      **Features**:     - Full-text search across title, description, abstract, text content     - Typo tolerance (finds \"machnie\" when searching for \"machine\")     - Relevance ranking based on TF-IDF and proximity     - Faceted filtering by dataset, status, MIME type, tags     - Sorting by date, size, relevance     - Highlighted search results      **Flow**:     1. Query is sent to Meilisearch     2. Full-text search across indexed fields     3. Filters are applied (dataset_id, status, etc.)     4. Results are ranked and highlighted     5. Metadata is returned (no S3 fetching)      **Performance**: Typically < 50ms for most queries      **503 Service Unavailable** with `Retry-After`: the index this search needs is not     ready, because its filterable and sortable attributes are not yet confirmed applied     by Meilisearch, for example right after the index was created.     Retry after the given number of seconds.      **Use cases**:     - Keyword-based document discovery     - Filtering by metadata (tags, type, dataset)     - Search with typo tolerance     - Faceted search interfaces     - Finding documents by title, author, abstract
      * Keyword/faceted search for documents
      */
     async keywordSearchApiV1SearchPostRaw(requestParameters: KeywordSearchApiV1SearchPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<KeywordSearchResponse>> {
@@ -143,7 +143,7 @@ export class SearchApi extends runtime.BaseAPI implements SearchApiInterface {
     }
 
     /**
-     * **Keyword search endpoint** - Search documents using Meilisearch for full-text and faceted search.      This endpoint provides fast keyword search with typo tolerance, relevance ranking,     and powerful filtering capabilities.      **Features**:     - Full-text search across title, description, abstract, text content     - Typo tolerance (finds \"machnie\" when searching for \"machine\")     - Relevance ranking based on TF-IDF and proximity     - Faceted filtering by dataset, status, MIME type, tags     - Sorting by date, size, relevance     - Highlighted search results      **Flow**:     1. Query is sent to Meilisearch     2. Full-text search across indexed fields     3. Filters are applied (dataset_id, status, etc.)     4. Results are ranked and highlighted     5. Metadata is returned (no S3 fetching)      **Performance**: Typically < 50ms for most queries      **Use cases**:     - Keyword-based document discovery     - Filtering by metadata (tags, type, dataset)     - Search with typo tolerance     - Faceted search interfaces     - Finding documents by title, author, abstract
+     * **Keyword search endpoint** - Search documents using Meilisearch for full-text and faceted search.      This endpoint provides fast keyword search with typo tolerance, relevance ranking,     and powerful filtering capabilities.      **Features**:     - Full-text search across title, description, abstract, text content     - Typo tolerance (finds \"machnie\" when searching for \"machine\")     - Relevance ranking based on TF-IDF and proximity     - Faceted filtering by dataset, status, MIME type, tags     - Sorting by date, size, relevance     - Highlighted search results      **Flow**:     1. Query is sent to Meilisearch     2. Full-text search across indexed fields     3. Filters are applied (dataset_id, status, etc.)     4. Results are ranked and highlighted     5. Metadata is returned (no S3 fetching)      **Performance**: Typically < 50ms for most queries      **503 Service Unavailable** with `Retry-After`: the index this search needs is not     ready, because its filterable and sortable attributes are not yet confirmed applied     by Meilisearch, for example right after the index was created.     Retry after the given number of seconds.      **Use cases**:     - Keyword-based document discovery     - Filtering by metadata (tags, type, dataset)     - Search with typo tolerance     - Faceted search interfaces     - Finding documents by title, author, abstract
      * Keyword/faceted search for documents
      */
     async keywordSearchApiV1SearchPost(requestParameters: KeywordSearchApiV1SearchPostRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<KeywordSearchResponse> {

package/src/src/apis/SyncApi.ts

@@ -4,7 +4,7 @@
  * Client Data API
  * Client Cluster Data API - Manifest-based storage service
  *
- * The version of the OpenAPI document: 2.2.1
+ * The version of the OpenAPI document: 2.3.2
  * 
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -30,7 +30,7 @@ import {
  */
 export interface SyncApiInterface {
     /**
-     * Get ground truth statistics for reconciliation.  The backend calls this endpoint to compare its catalog against the actual state of the cluster\'s database.  Returns:     - timestamp: Current server time     - datasets: List of datasets with entry counts and sizes     - totals: Aggregated statistics across all datasets
+     * Get ground truth statistics for reconciliation.  The backend calls this endpoint to compare its catalog against the actual state of the cluster\'s database.  One query over `datasets`: `entry_count` and `size_bytes` are the stored aggregates a trigger on `entries` keeps current, and `last_modified` is the last time an entry was added to the dataset, removed, moved in or out, or resized (`last_entry_modified_at`), or the dataset\'s own `updated_at` while it has never had one. Other entry updates (status, manifest) do not move it.  Returns:     - timestamp: Current server time     - datasets: List of datasets with entry counts and sizes     - totals: Aggregated statistics across all datasets
      * @summary Get Sync Summary
      * @param {*} [options] Override http request option.
      * @throws {RequiredError}
@@ -39,7 +39,7 @@ export interface SyncApiInterface {
     getSyncSummaryApiV1SyncSummaryGetRaw(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<{ [key: string]: any; }>>;
 
     /**
-     * Get ground truth statistics for reconciliation.  The backend calls this endpoint to compare its catalog against the actual state of the cluster\'s database.  Returns:     - timestamp: Current server time     - datasets: List of datasets with entry counts and sizes     - totals: Aggregated statistics across all datasets
+     * Get ground truth statistics for reconciliation.  The backend calls this endpoint to compare its catalog against the actual state of the cluster\'s database.  One query over `datasets`: `entry_count` and `size_bytes` are the stored aggregates a trigger on `entries` keeps current, and `last_modified` is the last time an entry was added to the dataset, removed, moved in or out, or resized (`last_entry_modified_at`), or the dataset\'s own `updated_at` while it has never had one. Other entry updates (status, manifest) do not move it.  Returns:     - timestamp: Current server time     - datasets: List of datasets with entry counts and sizes     - totals: Aggregated statistics across all datasets
      * Get Sync Summary
      */
     getSyncSummaryApiV1SyncSummaryGet(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<{ [key: string]: any; }>;
@@ -67,7 +67,7 @@ export interface SyncApiInterface {
 export class SyncApi extends runtime.BaseAPI implements SyncApiInterface {
 
     /**
-     * Get ground truth statistics for reconciliation.  The backend calls this endpoint to compare its catalog against the actual state of the cluster\'s database.  Returns:     - timestamp: Current server time     - datasets: List of datasets with entry counts and sizes     - totals: Aggregated statistics across all datasets
+     * Get ground truth statistics for reconciliation.  The backend calls this endpoint to compare its catalog against the actual state of the cluster\'s database.  One query over `datasets`: `entry_count` and `size_bytes` are the stored aggregates a trigger on `entries` keeps current, and `last_modified` is the last time an entry was added to the dataset, removed, moved in or out, or resized (`last_entry_modified_at`), or the dataset\'s own `updated_at` while it has never had one. Other entry updates (status, manifest) do not move it.  Returns:     - timestamp: Current server time     - datasets: List of datasets with entry counts and sizes     - totals: Aggregated statistics across all datasets
      * Get Sync Summary
      */
     async getSyncSummaryApiV1SyncSummaryGetRaw(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<{ [key: string]: any; }>> {
@@ -86,7 +86,7 @@ export class SyncApi extends runtime.BaseAPI implements SyncApiInterface {
     }
 
     /**
-     * Get ground truth statistics for reconciliation.  The backend calls this endpoint to compare its catalog against the actual state of the cluster\'s database.  Returns:     - timestamp: Current server time     - datasets: List of datasets with entry counts and sizes     - totals: Aggregated statistics across all datasets
+     * Get ground truth statistics for reconciliation.  The backend calls this endpoint to compare its catalog against the actual state of the cluster\'s database.  One query over `datasets`: `entry_count` and `size_bytes` are the stored aggregates a trigger on `entries` keeps current, and `last_modified` is the last time an entry was added to the dataset, removed, moved in or out, or resized (`last_entry_modified_at`), or the dataset\'s own `updated_at` while it has never had one. Other entry updates (status, manifest) do not move it.  Returns:     - timestamp: Current server time     - datasets: List of datasets with entry counts and sizes     - totals: Aggregated statistics across all datasets
      * Get Sync Summary
      */
     async getSyncSummaryApiV1SyncSummaryGet(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<{ [key: string]: any; }> {

package/src/src/apis/WebhooksApi.ts

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

package/src/src/apis/WeightsApi.ts

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

package/src/src/models/AdmissionLaneHealth.ts

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

package/src/src/models/ArtifactInputConfig.ts

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

package/src/src/models/BatchContentRequest.ts

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

package/src/src/models/BatchContentResponse.ts

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

package/src/src/models/BatchGetEntriesRequest.ts

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

package/src/src/models/BatchGetEntriesResponse.ts

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

package/src/src/models/BatchIngestError.ts

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

package/src/src/models/BatchIngestItemResult.ts

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

package/src/src/models/BatchIngestOutcome.ts

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

package/src/src/models/BatchIngestResponse.ts

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

package/src/src/models/ChunkSearchResponse.ts

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

package/src/src/models/ChunkSearchResult.ts

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

package/src/src/models/CollectionInfo.ts

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

package/src/src/models/ComponentArtifact.ts

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

package/src/src/models/ComponentListResponse.ts

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

package/src/src/models/ComponentMetadata.ts

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

package/src/src/models/ComponentParameter.ts

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

package/src/src/models/Dataset.ts

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

package/src/src/models/DatasetCreateRequest.ts

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

package/src/src/models/DatasetListResponse.ts

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

package/src/src/models/DatasetPipelineConfig.ts

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

package/src/src/models/DatasetResponse.ts

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

package/src/src/models/DatasetSchemaDefinition.ts

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

package/src/src/models/DatasetSchemaDefinitionCreate.ts

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

package/src/src/models/DatasetSchemaOriginal.ts

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

package/src/src/models/DatasetSchemaProcessed.ts

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

package/src/src/models/DatasetSchemaProcessing.ts

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

package/src/src/models/DatasetType.ts

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

package/src/src/models/DatasetUpdateRequest.ts

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

package/src/src/models/DatasetUpdateSchemaRequest.ts

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

package/src/src/models/Default.ts

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