Prior to v0.25, the Deletion Queue was synchronously processed on Job Creation
and stored in DynamoDB. As a result, the job API provided the full queue for a
given job in the DeletionQueueItems property and there was a limit of ~375KB
on the queue size for each individual Job. If the size for a given job would
have exceeded the allowed space, the DeletionQueueItemsSkipped property would
have been set to true and it would have been necessary to run one or more
deletion jobs, upon completion, to process the whole queue.
Starting from v0.25, the queue is processed asynchronously after job creation and is stored in S3 in order to remove the queue limit. As a result:
- The
DeletionQueueItemsSkippedandDeletionQueueItemsfields are removed from theGET /jobs/{job_id}andDELETE /queueAPIs. - A new Job Event is created when the Query Planning ends called
QueryPlanningCompletethat contains details of the query planning phase. - After Query Planning, the
QueryPlanningCompleteevent payload is available in theGET /jobs/{job_id}API for lookup of the properties:GeneratedQueriesis the number of queries planned for executionDeletionQueueSizeis the size of the queue for the JobManifestsis an array of S3 Objects containing the location for the Job manifests. There is a manifest for each combination ofJobIdandDataMapperId, and each manifest contains the full queue including the MatchIds.
- The manifests follow the same expiration policy as the Job Details (they will
get automatically removed if the
JobDetailsRetentionDaysparameter is configured when installing the solution). - If you relied on the removed
DeletionQueueItemsparameter to inspect the Job's queue, you'll need to migrate to fetching the S3 Manifests or querying the AWS Glue Manifests Table. - The deletion queue items are not visible in the UI anymore in the job details page or in the job JSON export.
The default behaviour of the solution has been changed in v0.9 to deploy and use a purpose-built VPC when creating the solution CloudFormation stack.
If you have deployed the standalone VPC stack provided in previous versions, you
should should set DeployVpc to true when upgrading to v0.9 and input the
same values for the FlowLogsGroup and FlowLogsRoleArn parameters that were
used when deploying the standalone VPC stack. After the deployment of v0.9 is
complete, you should delete the old VPC stack.
To continue using an existing VPC, you must set DeployVpc to false when
upgrading to v0.9.