Unify and manage your data

Run the Relations Consistency Check task

Learn more about how to run the Relations Consistency Check task to detect and fix inconsistencies between the RELATIONS and RELATIONS_ONE_HOP_NEW column families.

Use this task to check and fix consistency between the RELATIONS and RELATIONS_ONE_HOP_NEW column families. Stop and pause are supported.

HTTP method and endpoint

Use one of the following endpoints to submit the request:

POST {ApplicationURL}/relationsConsistencyCheck
POST {ApplicationURL}/api/{tenantId}/relationsConsistencyCheck

The admin role is required for POST {ApplicationURL}/relationsConsistencyCheck. The tenant admin role is required for POST {ApplicationURL}/api/{tenantId}/relationsConsistencyCheck.

Request headers

Include the following request headers.

HeaderValueRequired
Content-Typeapplication/jsonYes
AuthorizationBearer <access_token>Yes

Query parameters

The following table describes the supported query parameters.

ParameterTypeRequiredDescriptionAccepted values / Default
tenantIdStringYesThe ID of the tenant to check.Required for the tenant-scoped endpoint.
distributedBooleanNoIf set to true, the task runs in distributed mode. Multiple subtasks are created, and each subtask processes its own token range of relations in parallel across API nodes. This parameter is ignored when a request body is provided.true or false. Default: false.
taskPartsCountIntegerNoNumber of subtasks created for distributed execution. Each subtask processes its own token range. This parameter is used only when distributed=true.Default: 2.
readOnlyBooleanNoIf set to true, the task detects inconsistencies and reports them without making repairs. If set to false, the task inserts missing ONE_HOP records to fix inconsistencies.true or false. Default: false.
ignoreMaxOneHopTotalFetchSizeBooleanNoIf set to true, disables the tenant-configured maxOneHopTotalFetchSize limit while the task reads ONE_HOP records. This can help avoid incomplete reads on tenants with highly connected entities.true or false. Default: false.
relationTypeStringNoChecks only relations of the specified type or types. Supports comma-separated values for multiple relation types.If omitted, all relation types are checked.
maxResultsToStoreIntegerNoMaximum number of consistency errors to store in the task results.Default: 20.
updatedSinceLongNoUNIX timestamp. If specified, only relations with an updatedTime greater than or equal to this value are checked.UNIX timestamp.
updatedTillLongNoUNIX timestamp. If specified, only relations with an updatedTime less than or equal to this value are checked. You can use this parameter together with updatedSince to define a time range.UNIX timestamp.

Request body

You can optionally provide a JSON array of relation IDs. If you do not provide a request body, the task runs for the whole tenant.

ParameterTypeRequiredDescriptionAccepted values / Default
bodyArray<String>NoArray of relation IDs to check.Example: ["relations/14vev8xH"]. If omitted, the task runs for the whole tenant.

Example request

The following example starts the task for a tenant and limits processing to the specified relation types.

POST {ApplicationURL}/api/{tenantId}/relationsConsistencyCheck?distributed=true&taskPartsCount=4&readOnly=true&relationType=HasAddress,HasContact
Authorization: Bearer <access_token>
Content-Type: application/json

Example request with body

The following example runs the task only for the specified relation IDs.

POST {ApplicationURL}/api/{tenantId}/relationsConsistencyCheck
Authorization: Bearer <access_token>
Content-Type: application/json

[
  "relations/14vev8xH"
]

Example response

This operation starts a background task. The response returns the created task information.

{
  "id": "a1b2c3d4e5",
  "type": "relationsConsistencyCheck",
  "status": "SCHEDULED"
}

Response fields

The following table describes the common fields returned when the task is created.

FieldTypeDescription
idStringUnique identifier of the created task.
typeStringTask type.
statusStringCurrent task status.