Skip to content
Qualia Docs

Datasets_ReingestDataset

POST
/v1/accounts/{account}/datasets/{dataset}:reingest
 
curl --request POST \
  --url https://dev-api.qualiastudios.dev/v1/accounts/example/datasets/example:reingest \
  --header 'Content-Type: application/json' \
  --header 'X-API-Key: <X-API-Key>' \
  --data '{ "name": "example", "ingestConfig": "example", "mergedSettingsContext": { "mergedDataset": "example", "members": [ "example" ], "membershipRevision": "example", "etag": "example", "sourceCommit": "example" }, "requestId": "example", "resumeReingest": "example" }'

Upload only (MCAP): commits a new meta/ingest.toml and ingests the unchanged recordings again under it, publishing the upload’s next generation (ADR 0012). Returns once the work is admitted; the ingest takes minutes and is read with GetReingest. A config identical to the published one runs nothing and returns that publication, SUCCEEDED, with unchanged set.

A config that declares [episodes] spans re-cuts the recordings at those windows. Episode ids follow position, so a re-cut renumbers every episode of the upload: it is FAILED_PRECONDITION, naming the counts, while any episode holds a person ruling, a person issue or note, a reach result, an edit or a split child.

FAILED_PRECONDITION on a mixture, a non-MCAP upload, a merged dataset (QUA-3511: re-ingest its uploads before they merge) and an upload merged into one (naming it; its GetReingest and GetIngestReport still answer); INVALID_ARGUMENT when the config does not parse.

Authorizations

Section titled “Authorizations ”

Parameters

Section titled “ Parameters ”

Path Parameters

Section titled “Path Parameters ”
account
required
string

The account id.

dataset
required
string

The dataset id.

Request Body required

Section titled “Request Body required ”
Media type application/json

Request for Datasets.ReingestDataset.

object
name
required

Accounts/{account}/datasets/{dataset}

string
ingestConfig

Required unless resume_reingest is set. The complete meta/ingest.toml (schema = 1). It replaces the published file: a table the published file declared and this one leaves out is dropped. Declaring [episodes] spans re-cuts the upload (see ReingestDataset). With merged_settings_context this is instead a strict clock/alignment patch: only schema, clock and channels..align are accepted. Omitted clock keeps it; empty [clock] resets clock/grid/source overrides to automatic. In a nonempty clock table, a supplied fixed_hz or row_clock_topic replaces the grid, and source changes only if supplied. Explicit align = “nearest” resets alignment; omitted topics keep theirs. Unknown/unrouted topics and every other key are refused. The server composes onto the exact captured head, retaining episode boundaries, rig, camera settings and per-channel timestamp offsets.

string
mergedSettingsContext

Explicitly confirmed MCAP clock/alignment edit of one merged member. Other config tables and episode boundaries must remain unchanged. Older callers without this context retain the existing member re-cut rules.

object
mergedDataset
required

The merged dataset whose membership was confirmed.

string
members
required

Every upload it held, in merge order, including the selected upload.

Array<string>
membershipRevision
required

Opaque merge/undo epoch from GetDataset; never recapture it on retry.

string
etag
required

The dataset’s editable etag; a member edit sends the selected upload’s.

string
sourceCommit

The selected upload’s exact paired head. Empty on the merged dataset’s context, which is used only to fence global label edits.

string
requestId

UUID retry key, required with merged_settings_context. A replay retains its original operation and membership scope, never today’s membership.

string
resumeReingest

Resume this exact completed corrective publication. No ingest_config, request_id or merged_settings_context may accompany this operation.

string
Example generated
{
  "name": "example",
  "ingestConfig": "example",
  "mergedSettingsContext": {
    "mergedDataset": "example",
    "members": [
      "example"
    ],
    "membershipRevision": "example",
    "etag": "example",
    "sourceCommit": "example"
  },
  "requestId": "example",
  "resumeReingest": "example"
}

Responses

Section titled “ Responses ”

200

Section titled “200 ”

OK

Media type application/json

Response for Datasets.ReingestDataset.

object
reingest

The re-ingest it admitted (QUEUED), or with unchanged set, the publication that already carries the config (SUCCEEDED).

object
name

Accounts/{account}/datasets/{dataset}/reingests/{reingest}

string
state

Where the work stands.

string format: enum
Allowed values: STATE_UNSPECIFIED QUEUED PREPARING PUBLISHING SUCCEEDED FAILED
unchanged

The posted config was the published one: nothing ran, and this names the publication that already carries it.

boolean
failureReason

Why it failed; empty unless FAILED.

string
progress

While PREPARING: the live step, the same open set of fields the upload feed reports (step, detail, counters).

object
episodeCount

Once SUCCEEDED: episodes in the published generation.

string
frameCount

Once SUCCEEDED: frames in the published generation.

string
poseAttempt

Attempt currently preparing a pose move, or zero when cancellation is unavailable.

integer format: int32
publicationFailure

Most recent safe publication failure while publishing, if any.

string
recutResult

Present only when a verified re-cut result committed atomically with this successful publication. Absence is not an empty/clean result.

object
notCarriedCount

Exact number of old original takes with state not carried. Zero means the verified publication lost no state; no such take is listed.

string
publicationCommit

Immutable publication commit, used to bind every page of the result.

string
Example 
{
  "reingest": {
    "state": "STATE_UNSPECIFIED"
  }
}

default

Section titled “default ”

Default error response

Media type application/json

The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.

object
code

The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].

integer format: int32
message

A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.

string
details

A list of messages that carry the error details. There is a common set of message types for APIs to use.

Array<object>

Contains an arbitrary serialized message along with a @type that describes the type of the serialized message.

object
@type

The type of the serialized message.

string
key
additional properties
any
Example generated
{
  "code": 1,
  "message": "example",
  "details": [
    {
      "@type": "example"
    }
  ]
}