Any mutations in Skylark require additional processing after the response has been returned. This processing involves updating availability, relationships and translations among other things.

This means that after an object has been created, updated or deleted, there will be a delay before the changes are fully reflected.

This delay will increase or decrease depending on current activity. For example, during a large ingest where the queue of background tasks is very long, tasks can stay queued for multiple hours before being processed, whereas in quieter times the delay will barely be noticeable.

Viewing Tasks

For all mutations that require background processing, the task_id can be retrieved from the mutation _context.

Upon completion, tasks remain visible for 24 hours.

For example:

mutation {
  createMovie(movie: {
    title: "My movie",
    availability: {
      link: ["always"]
    }
  }) {
    uid
    _context {
      task_id
    }
  }
}

This will return:

{
  "data": {
    "createMovie": {
      "uid": "01HEAMD69Q4A0B8KDA9V2D67KA",
      "_context": {
        "task_id": "e633e5da-af1b-4df1-8b8a-366603e6232b"
      }
    }
  }
}

The task_id in the response can be used to get information on the task using the getSkylarkBackgroundTask query.

{
  getSkylarkBackgroundTask(task_id: "e633e5da-af1b-4df1-8b8a-366603e6232b") {
    task_id
    created_at
    updated_at
    status
    task_type
    object_uid
    messages
  }
}

The task returned by the API returns the following fields:

Field	Returns	Description
`task_id`		The UUID of the task
`created_at`		The time the task was originally created
`updated_at`		The time of the most recent update on the task
`status`	This can be one of the following:	The current state of the task.
	`QUEUED`	Task is waiting in the queue to be processed
	`IN_PROGRESS`	Task processing has started
	`COMPLETE`	Task processing has completed successfully
	`FAILED`	Task processing has failed
`task_type`	This can be one of the following:	The type of task being processed.
	`post_create`	Task that runs after an object is created
	`post_update`	Task that runs after an object is updated
	`post_delete`	Task that runs after an object is deleted
	`batch_delete`	Task that deletes many objects (this in turn triggers `post_delete` tasks)
	`availability_update`	Task that runs after availability rule is updated (this in turn triggers `post_update_availability`)
	`availability_delete`	Task that runs after an availability rule is deleted (this in turn triggers `post_delete_availability`)
	`post_update_availability`	Task that runs after `availability_update` task to update object availability
	`post_delete_availability`	Task that runs after `availability_delete` task to update object availability
`object_uid`		UID of the object effected by the task
`messages`		Messages with task updates. These messages will also show any errors that were raised during the task processing.

An example of the response:

{
  "data": {
    "getSkylarkBackgroundTask": {
      "status": "COMPLETE",
      "updated_at": "2023-11-03T13:02:25.584885+00:00",
      "task_type": "post_create",
      "task_id": "e633e5da-af1b-4df1-8b8a-366603e6232b",
      "object_uid": "01HEAMD69Q4A0B8KDA9V2D67KA",
      "messages": [
        "Job started",
        "Starting availability creation",
        "Availability creation complete",
        "Starting availability post-processing",
        "Availability post-processing complete"
      ],
      "created_at": "2023-11-03T13:01:52.302002+00:00"
    }
  }
}

Listing Background Tasks

It's also possible to list many background tasks using the listSkylarkBackgroundTask query.

{
  listSkylarkBackgroundTask {
    objects {
      task_id
      created_at
      updated_at
      status
      task_type
      object_uid
      messages
    }
  }
}

And filter the list by a specific status with the status argument.

{
  listSkylarkBackgroundTask(status: IN_PROGRESS) {
    objects {
      task_id
      created_at
      updated_at
      status
      task_type
      object_uid
      messages
    }
  }
}