google-native.cloudtasks/v2beta2.Queue

App Engine HTTP target. An App Engine queue is a queue that has an AppEngineHttpTarget.

An http_target is used to override the target values for HTTP tasks.

Caller-specified and required in CreateQueue, after which it becomes output only. The queue name. The queue name must have the following format: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID * PROJECT_ID can contain letters ([A-Za-z]), numbers ([0-9]), hyphens (-), colons (:), or periods (.). For more information, see Identifying projects * LOCATION_ID is the canonical ID for the queue's location. The list of available locations can be obtained by calling ListLocations. For more information, see https://cloud.google.com/about/locations/. * QUEUE_ID can contain letters ([A-Za-z]), numbers ([0-9]), or hyphens (-). The maximum length is 100 characters.

Pull target. A pull queue is a queue that has a PullTarget.

Rate limits for task dispatches. rate_limits and retry_config are related because they both control task attempts however they control how tasks are attempted in different ways: * rate_limits controls the total rate of dispatches from a queue (i.e. all traffic dispatched from the queue, regardless of whether the dispatch is from a first attempt or a retry). * retry_config controls what happens to particular a task after its first attempt fails. That is, retry_config controls task retries (the second attempt, third attempt, etc).

Settings that determine the retry behavior. * For tasks created using Cloud Tasks: the queue-level retry settings apply to all tasks in the queue that were created using Cloud Tasks. Retry settings cannot be set on individual tasks. * For tasks created using the App Engine SDK: the queue-level retry settings apply to all tasks in the queue which do not have retry settings explicitly set on the task and were created by the App Engine SDK. See App Engine documentation.

The maximum amount of time that a task will be retained in this queue. Queues created by Cloud Tasks have a default task_ttl of 31 days. After a task has lived for task_ttl, the task will be deleted regardless of whether it was dispatched or not. The task_ttl for queues created via queue.yaml/xml is equal to the maximum duration because there is a storage quota for these queues. To view the maximum valid duration, see the documentation for Duration.

The task tombstone time to live (TTL). After a task is deleted or completed, the task's tombstone is retained for the length of time specified by tombstone_ttl. The tombstone is used by task de-duplication; another task with the same name can't be created until the tombstone has expired. For more information about task de-duplication, see the documentation for CreateTaskRequest. Queues created by Cloud Tasks have a default tombstone_ttl of 1 hour.

App Engine HTTP target. An App Engine queue is a queue that has an AppEngineHttpTarget.

An http_target is used to override the target values for HTTP tasks.

Caller-specified and required in CreateQueue, after which it becomes output only. The queue name. The queue name must have the following format: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID * PROJECT_ID can contain letters ([A-Za-z]), numbers ([0-9]), hyphens (-), colons (:), or periods (.). For more information, see Identifying projects * LOCATION_ID is the canonical ID for the queue's location. The list of available locations can be obtained by calling ListLocations. For more information, see https://cloud.google.com/about/locations/. * QUEUE_ID can contain letters ([A-Za-z]), numbers ([0-9]), or hyphens (-). The maximum length is 100 characters.

Pull target. A pull queue is a queue that has a PullTarget.

Rate limits for task dispatches. rate_limits and retry_config are related because they both control task attempts however they control how tasks are attempted in different ways: * rate_limits controls the total rate of dispatches from a queue (i.e. all traffic dispatched from the queue, regardless of whether the dispatch is from a first attempt or a retry). * retry_config controls what happens to particular a task after its first attempt fails. That is, retry_config controls task retries (the second attempt, third attempt, etc).

Settings that determine the retry behavior. * For tasks created using Cloud Tasks: the queue-level retry settings apply to all tasks in the queue that were created using Cloud Tasks. Retry settings cannot be set on individual tasks. * For tasks created using the App Engine SDK: the queue-level retry settings apply to all tasks in the queue which do not have retry settings explicitly set on the task and were created by the App Engine SDK. See App Engine documentation.

The maximum amount of time that a task will be retained in this queue. Queues created by Cloud Tasks have a default task_ttl of 31 days. After a task has lived for task_ttl, the task will be deleted regardless of whether it was dispatched or not. The task_ttl for queues created via queue.yaml/xml is equal to the maximum duration because there is a storage quota for these queues. To view the maximum valid duration, see the documentation for Duration.

The task tombstone time to live (TTL). After a task is deleted or completed, the task's tombstone is retained for the length of time specified by tombstone_ttl. The tombstone is used by task de-duplication; another task with the same name can't be created until the tombstone has expired. For more information about task de-duplication, see the documentation for CreateTaskRequest. Queues created by Cloud Tasks have a default tombstone_ttl of 1 hour.

App Engine HTTP target. An App Engine queue is a queue that has an AppEngineHttpTarget.

An http_target is used to override the target values for HTTP tasks.

Caller-specified and required in CreateQueue, after which it becomes output only. The queue name. The queue name must have the following format: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID * PROJECT_ID can contain letters ([A-Za-z]), numbers ([0-9]), hyphens (-), colons (:), or periods (.). For more information, see Identifying projects * LOCATION_ID is the canonical ID for the queue's location. The list of available locations can be obtained by calling ListLocations. For more information, see https://cloud.google.com/about/locations/. * QUEUE_ID can contain letters ([A-Za-z]), numbers ([0-9]), or hyphens (-). The maximum length is 100 characters.

Pull target. A pull queue is a queue that has a PullTarget.

Rate limits for task dispatches. rate_limits and retry_config are related because they both control task attempts however they control how tasks are attempted in different ways: * rate_limits controls the total rate of dispatches from a queue (i.e. all traffic dispatched from the queue, regardless of whether the dispatch is from a first attempt or a retry). * retry_config controls what happens to particular a task after its first attempt fails. That is, retry_config controls task retries (the second attempt, third attempt, etc).

Settings that determine the retry behavior. * For tasks created using Cloud Tasks: the queue-level retry settings apply to all tasks in the queue that were created using Cloud Tasks. Retry settings cannot be set on individual tasks. * For tasks created using the App Engine SDK: the queue-level retry settings apply to all tasks in the queue which do not have retry settings explicitly set on the task and were created by the App Engine SDK. See App Engine documentation.

The maximum amount of time that a task will be retained in this queue. Queues created by Cloud Tasks have a default task_ttl of 31 days. After a task has lived for task_ttl, the task will be deleted regardless of whether it was dispatched or not. The task_ttl for queues created via queue.yaml/xml is equal to the maximum duration because there is a storage quota for these queues. To view the maximum valid duration, see the documentation for Duration.

The task tombstone time to live (TTL). After a task is deleted or completed, the task's tombstone is retained for the length of time specified by tombstone_ttl. The tombstone is used by task de-duplication; another task with the same name can't be created until the tombstone has expired. For more information about task de-duplication, see the documentation for CreateTaskRequest. Queues created by Cloud Tasks have a default tombstone_ttl of 1 hour.

App Engine HTTP target. An App Engine queue is a queue that has an AppEngineHttpTarget.

An http_target is used to override the target values for HTTP tasks.

Caller-specified and required in CreateQueue, after which it becomes output only. The queue name. The queue name must have the following format: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID * PROJECT_ID can contain letters ([A-Za-z]), numbers ([0-9]), hyphens (-), colons (:), or periods (.). For more information, see Identifying projects * LOCATION_ID is the canonical ID for the queue's location. The list of available locations can be obtained by calling ListLocations. For more information, see https://cloud.google.com/about/locations/. * QUEUE_ID can contain letters ([A-Za-z]), numbers ([0-9]), or hyphens (-). The maximum length is 100 characters.

Pull target. A pull queue is a queue that has a PullTarget.

Rate limits for task dispatches. rate_limits and retry_config are related because they both control task attempts however they control how tasks are attempted in different ways: * rate_limits controls the total rate of dispatches from a queue (i.e. all traffic dispatched from the queue, regardless of whether the dispatch is from a first attempt or a retry). * retry_config controls what happens to particular a task after its first attempt fails. That is, retry_config controls task retries (the second attempt, third attempt, etc).

Settings that determine the retry behavior. * For tasks created using Cloud Tasks: the queue-level retry settings apply to all tasks in the queue that were created using Cloud Tasks. Retry settings cannot be set on individual tasks. * For tasks created using the App Engine SDK: the queue-level retry settings apply to all tasks in the queue which do not have retry settings explicitly set on the task and were created by the App Engine SDK. See App Engine documentation.

The maximum amount of time that a task will be retained in this queue. Queues created by Cloud Tasks have a default task_ttl of 31 days. After a task has lived for task_ttl, the task will be deleted regardless of whether it was dispatched or not. The task_ttl for queues created via queue.yaml/xml is equal to the maximum duration because there is a storage quota for these queues. To view the maximum valid duration, see the documentation for Duration.

The task tombstone time to live (TTL). After a task is deleted or completed, the task's tombstone is retained for the length of time specified by tombstone_ttl. The tombstone is used by task de-duplication; another task with the same name can't be created until the tombstone has expired. For more information about task de-duplication, see the documentation for CreateTaskRequest. Queues created by Cloud Tasks have a default tombstone_ttl of 1 hour.

App Engine HTTP target. An App Engine queue is a queue that has an AppEngineHttpTarget.

An http_target is used to override the target values for HTTP tasks.

Caller-specified and required in CreateQueue, after which it becomes output only. The queue name. The queue name must have the following format: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID * PROJECT_ID can contain letters ([A-Za-z]), numbers ([0-9]), hyphens (-), colons (:), or periods (.). For more information, see Identifying projects * LOCATION_ID is the canonical ID for the queue's location. The list of available locations can be obtained by calling ListLocations. For more information, see https://cloud.google.com/about/locations/. * QUEUE_ID can contain letters ([A-Za-z]), numbers ([0-9]), or hyphens (-). The maximum length is 100 characters.

Pull target. A pull queue is a queue that has a PullTarget.

Rate limits for task dispatches. rate_limits and retry_config are related because they both control task attempts however they control how tasks are attempted in different ways: * rate_limits controls the total rate of dispatches from a queue (i.e. all traffic dispatched from the queue, regardless of whether the dispatch is from a first attempt or a retry). * retry_config controls what happens to particular a task after its first attempt fails. That is, retry_config controls task retries (the second attempt, third attempt, etc).

Settings that determine the retry behavior. * For tasks created using Cloud Tasks: the queue-level retry settings apply to all tasks in the queue that were created using Cloud Tasks. Retry settings cannot be set on individual tasks. * For tasks created using the App Engine SDK: the queue-level retry settings apply to all tasks in the queue which do not have retry settings explicitly set on the task and were created by the App Engine SDK. See App Engine documentation.

The maximum amount of time that a task will be retained in this queue. Queues created by Cloud Tasks have a default task_ttl of 31 days. After a task has lived for task_ttl, the task will be deleted regardless of whether it was dispatched or not. The task_ttl for queues created via queue.yaml/xml is equal to the maximum duration because there is a storage quota for these queues. To view the maximum valid duration, see the documentation for Duration.

The task tombstone time to live (TTL). After a task is deleted or completed, the task's tombstone is retained for the length of time specified by tombstone_ttl. The tombstone is used by task de-duplication; another task with the same name can't be created until the tombstone has expired. For more information about task de-duplication, see the documentation for CreateTaskRequest. Queues created by Cloud Tasks have a default tombstone_ttl of 1 hour.

App Engine HTTP target. An App Engine queue is a queue that has an AppEngineHttpTarget.

An http_target is used to override the target values for HTTP tasks.

Caller-specified and required in CreateQueue, after which it becomes output only. The queue name. The queue name must have the following format: projects/PROJECT_ID/locations/LOCATION_ID/queues/QUEUE_ID * PROJECT_ID can contain letters ([A-Za-z]), numbers ([0-9]), hyphens (-), colons (:), or periods (.). For more information, see Identifying projects * LOCATION_ID is the canonical ID for the queue's location. The list of available locations can be obtained by calling ListLocations. For more information, see https://cloud.google.com/about/locations/. * QUEUE_ID can contain letters ([A-Za-z]), numbers ([0-9]), or hyphens (-). The maximum length is 100 characters.

Pull target. A pull queue is a queue that has a PullTarget.

Rate limits for task dispatches. rate_limits and retry_config are related because they both control task attempts however they control how tasks are attempted in different ways: * rate_limits controls the total rate of dispatches from a queue (i.e. all traffic dispatched from the queue, regardless of whether the dispatch is from a first attempt or a retry). * retry_config controls what happens to particular a task after its first attempt fails. That is, retry_config controls task retries (the second attempt, third attempt, etc).

Settings that determine the retry behavior. * For tasks created using Cloud Tasks: the queue-level retry settings apply to all tasks in the queue that were created using Cloud Tasks. Retry settings cannot be set on individual tasks. * For tasks created using the App Engine SDK: the queue-level retry settings apply to all tasks in the queue which do not have retry settings explicitly set on the task and were created by the App Engine SDK. See App Engine documentation.

The maximum amount of time that a task will be retained in this queue. Queues created by Cloud Tasks have a default task_ttl of 31 days. After a task has lived for task_ttl, the task will be deleted regardless of whether it was dispatched or not. The task_ttl for queues created via queue.yaml/xml is equal to the maximum duration because there is a storage quota for these queues. To view the maximum valid duration, see the documentation for Duration.

The task tombstone time to live (TTL). After a task is deleted or completed, the task's tombstone is retained for the length of time specified by tombstone_ttl. The tombstone is used by task de-duplication; another task with the same name can't be created until the tombstone has expired. For more information about task de-duplication, see the documentation for CreateTaskRequest. Queues created by Cloud Tasks have a default tombstone_ttl of 1 hour.

The provider-assigned unique ID for this managed resource.

The last time this queue was purged. All tasks that were created before this time were purged. A queue can be purged using PurgeQueue, the App Engine Task Queue SDK, or the Cloud Console. Purge time will be truncated to the nearest microsecond. Purge time will be unset if the queue has never been purged.

The state of the queue. state can only be changed by called PauseQueue, ResumeQueue, or uploading queue.yaml/xml. UpdateQueue cannot be used to change state.

The realtime, informational statistics for a queue. In order to receive the statistics the caller should include this field in the FieldMask.

The provider-assigned unique ID for this managed resource.

The last time this queue was purged. All tasks that were created before this time were purged. A queue can be purged using PurgeQueue, the App Engine Task Queue SDK, or the Cloud Console. Purge time will be truncated to the nearest microsecond. Purge time will be unset if the queue has never been purged.

The state of the queue. state can only be changed by called PauseQueue, ResumeQueue, or uploading queue.yaml/xml. UpdateQueue cannot be used to change state.

The realtime, informational statistics for a queue. In order to receive the statistics the caller should include this field in the FieldMask.

The provider-assigned unique ID for this managed resource.

The last time this queue was purged. All tasks that were created before this time were purged. A queue can be purged using PurgeQueue, the App Engine Task Queue SDK, or the Cloud Console. Purge time will be truncated to the nearest microsecond. Purge time will be unset if the queue has never been purged.

The state of the queue. state can only be changed by called PauseQueue, ResumeQueue, or uploading queue.yaml/xml. UpdateQueue cannot be used to change state.

The realtime, informational statistics for a queue. In order to receive the statistics the caller should include this field in the FieldMask.

The provider-assigned unique ID for this managed resource.

The last time this queue was purged. All tasks that were created before this time were purged. A queue can be purged using PurgeQueue, the App Engine Task Queue SDK, or the Cloud Console. Purge time will be truncated to the nearest microsecond. Purge time will be unset if the queue has never been purged.

The state of the queue. state can only be changed by called PauseQueue, ResumeQueue, or uploading queue.yaml/xml. UpdateQueue cannot be used to change state.

The realtime, informational statistics for a queue. In order to receive the statistics the caller should include this field in the FieldMask.

The provider-assigned unique ID for this managed resource.

The last time this queue was purged. All tasks that were created before this time were purged. A queue can be purged using PurgeQueue, the App Engine Task Queue SDK, or the Cloud Console. Purge time will be truncated to the nearest microsecond. Purge time will be unset if the queue has never been purged.

The state of the queue. state can only be changed by called PauseQueue, ResumeQueue, or uploading queue.yaml/xml. UpdateQueue cannot be used to change state.

The realtime, informational statistics for a queue. In order to receive the statistics the caller should include this field in the FieldMask.

The provider-assigned unique ID for this managed resource.

The last time this queue was purged. All tasks that were created before this time were purged. A queue can be purged using PurgeQueue, the App Engine Task Queue SDK, or the Cloud Console. Purge time will be truncated to the nearest microsecond. Purge time will be unset if the queue has never been purged.

The state of the queue. state can only be changed by called PauseQueue, ResumeQueue, or uploading queue.yaml/xml. UpdateQueue cannot be used to change state.

The realtime, informational statistics for a queue. In order to receive the statistics the caller should include this field in the FieldMask.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

Overrides for the task-level app_engine_routing. If set, app_engine_routing_override is used for all tasks in the queue, no matter what the setting is for the task-level app_engine_routing.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

The host that the task is sent to. For more information, see How Requests are Routed. The host is constructed as: * host = [application_domain_name] | [service] + '.' + [application_domain_name] | [version] + '.' + [application_domain_name] | [version_dot_service]+ '.' + [application_domain_name] | [instance] + '.' + [application_domain_name] | [instance_dot_service] + '.' + [application_domain_name] | [instance_dot_version] + '.' + [application_domain_name] | [instance_dot_version_dot_service] + '.' + [application_domain_name] * application_domain_name = The domain name of the app, for example .appspot.com, which is associated with the queue's project ID. Some tasks which were created using the App Engine SDK use a custom domain name. * service = service * version = version * version_dot_service = version + '.' + service * instance = instance * instance_dot_service = instance + '.' + service * instance_dot_version = instance + '.' + version * instance_dot_version_dot_service = instance + '.' + version + '.' + service If service is empty, then the task will be sent to the service which is the default service when the task is attempted. If version is empty, then the task will be sent to the version which is the default version when the task is attempted. If instance is empty, then the task will be sent to an instance which is available when the task is attempted. If service, version, or instance is invalid, then the task will be sent to the default version of the default service when the task is attempted.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

The host that the task is sent to. For more information, see How Requests are Routed. The host is constructed as: * host = [application_domain_name] | [service] + '.' + [application_domain_name] | [version] + '.' + [application_domain_name] | [version_dot_service]+ '.' + [application_domain_name] | [instance] + '.' + [application_domain_name] | [instance_dot_service] + '.' + [application_domain_name] | [instance_dot_version] + '.' + [application_domain_name] | [instance_dot_version_dot_service] + '.' + [application_domain_name] * application_domain_name = The domain name of the app, for example .appspot.com, which is associated with the queue's project ID. Some tasks which were created using the App Engine SDK use a custom domain name. * service = service * version = version * version_dot_service = version + '.' + service * instance = instance * instance_dot_service = instance + '.' + service * instance_dot_version = instance + '.' + version * instance_dot_version_dot_service = instance + '.' + version + '.' + service If service is empty, then the task will be sent to the service which is the default service when the task is attempted. If version is empty, then the task will be sent to the version which is the default version when the task is attempted. If instance is empty, then the task will be sent to an instance which is available when the task is attempted. If service, version, or instance is invalid, then the task will be sent to the default version of the default service when the task is attempted.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

The host that the task is sent to. For more information, see How Requests are Routed. The host is constructed as: * host = [application_domain_name] | [service] + '.' + [application_domain_name] | [version] + '.' + [application_domain_name] | [version_dot_service]+ '.' + [application_domain_name] | [instance] + '.' + [application_domain_name] | [instance_dot_service] + '.' + [application_domain_name] | [instance_dot_version] + '.' + [application_domain_name] | [instance_dot_version_dot_service] + '.' + [application_domain_name] * application_domain_name = The domain name of the app, for example .appspot.com, which is associated with the queue's project ID. Some tasks which were created using the App Engine SDK use a custom domain name. * service = service * version = version * version_dot_service = version + '.' + service * instance = instance * instance_dot_service = instance + '.' + service * instance_dot_version = instance + '.' + version * instance_dot_version_dot_service = instance + '.' + version + '.' + service If service is empty, then the task will be sent to the service which is the default service when the task is attempted. If version is empty, then the task will be sent to the version which is the default version when the task is attempted. If instance is empty, then the task will be sent to an instance which is available when the task is attempted. If service, version, or instance is invalid, then the task will be sent to the default version of the default service when the task is attempted.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

The host that the task is sent to. For more information, see How Requests are Routed. The host is constructed as: * host = [application_domain_name] | [service] + '.' + [application_domain_name] | [version] + '.' + [application_domain_name] | [version_dot_service]+ '.' + [application_domain_name] | [instance] + '.' + [application_domain_name] | [instance_dot_service] + '.' + [application_domain_name] | [instance_dot_version] + '.' + [application_domain_name] | [instance_dot_version_dot_service] + '.' + [application_domain_name] * application_domain_name = The domain name of the app, for example .appspot.com, which is associated with the queue's project ID. Some tasks which were created using the App Engine SDK use a custom domain name. * service = service * version = version * version_dot_service = version + '.' + service * instance = instance * instance_dot_service = instance + '.' + service * instance_dot_version = instance + '.' + version * instance_dot_version_dot_service = instance + '.' + version + '.' + service If service is empty, then the task will be sent to the service which is the default service when the task is attempted. If version is empty, then the task will be sent to the version which is the default version when the task is attempted. If instance is empty, then the task will be sent to an instance which is available when the task is attempted. If service, version, or instance is invalid, then the task will be sent to the default version of the default service when the task is attempted.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

The host that the task is sent to. For more information, see How Requests are Routed. The host is constructed as: * host = [application_domain_name] | [service] + '.' + [application_domain_name] | [version] + '.' + [application_domain_name] | [version_dot_service]+ '.' + [application_domain_name] | [instance] + '.' + [application_domain_name] | [instance_dot_service] + '.' + [application_domain_name] | [instance_dot_version] + '.' + [application_domain_name] | [instance_dot_version_dot_service] + '.' + [application_domain_name] * application_domain_name = The domain name of the app, for example .appspot.com, which is associated with the queue's project ID. Some tasks which were created using the App Engine SDK use a custom domain name. * service = service * version = version * version_dot_service = version + '.' + service * instance = instance * instance_dot_service = instance + '.' + service * instance_dot_version = instance + '.' + version * instance_dot_version_dot_service = instance + '.' + version + '.' + service If service is empty, then the task will be sent to the service which is the default service when the task is attempted. If version is empty, then the task will be sent to the version which is the default version when the task is attempted. If instance is empty, then the task will be sent to an instance which is available when the task is attempted. If service, version, or instance is invalid, then the task will be sent to the default version of the default service when the task is attempted.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

The host that the task is sent to. For more information, see How Requests are Routed. The host is constructed as: * host = [application_domain_name] | [service] + '.' + [application_domain_name] | [version] + '.' + [application_domain_name] | [version_dot_service]+ '.' + [application_domain_name] | [instance] + '.' + [application_domain_name] | [instance_dot_service] + '.' + [application_domain_name] | [instance_dot_version] + '.' + [application_domain_name] | [instance_dot_version_dot_service] + '.' + [application_domain_name] * application_domain_name = The domain name of the app, for example .appspot.com, which is associated with the queue's project ID. Some tasks which were created using the App Engine SDK use a custom domain name. * service = service * version = version * version_dot_service = version + '.' + service * instance = instance * instance_dot_service = instance + '.' + service * instance_dot_version = instance + '.' + version * instance_dot_version_dot_service = instance + '.' + version + '.' + service If service is empty, then the task will be sent to the service which is the default service when the task is attempted. If version is empty, then the task will be sent to the version which is the default version when the task is attempted. If instance is empty, then the task will be sent to an instance which is available when the task is attempted. If service, version, or instance is invalid, then the task will be sent to the default version of the default service when the task is attempted.

App instance. By default, the task is sent to an instance which is available when the task is attempted. Requests can only be sent to a specific instance if manual scaling is used in App Engine Standard. App Engine Flex does not support instances. For more information, see App Engine Standard request routing and App Engine Flex request routing.

App service. By default, the task is sent to the service which is the default service when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

App version. By default, the task is sent to the version which is the default version when the task is attempted. For some queues or tasks which were created using the App Engine Task Queue API, host is not parsable into service, version, and instance. For example, some tasks which were created using the App Engine SDK use a custom domain name; custom domains are not parsed by Cloud Tasks. If host is not parsable, then service, version, and instance are the empty string.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

header embodying a key and a value.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

The key of the header.

The value of the header.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

HTTP target headers. This map contains the header field names and values. Headers will be set when running the task is created and/or task is created. These headers represent a subset of the headers that will accompany the task's HTTP request. Some HTTP request headers will be ignored or replaced. A partial list of headers that will be ignored or replaced is: * Any header that is prefixed with "X-CloudTasks-" will be treated as service header. Service headers define properties of the task and are predefined in CloudTask. * Host: This will be computed by Cloud Tasks and derived from HttpRequest.url. * Content-Length: This will be computed by Cloud Tasks. * User-Agent: This will be set to "Google-CloudTasks". * X-Google-*: Google use only. * X-AppEngine-*: Google use only. Content-Type won't be set by Cloud Tasks. You can explicitly set Content-Type to a media type when the task is created. For example, Content-Type can be set to "application/octet-stream" or "application/json". Headers which can have multiple values (according to RFC2616) can be specified using comma-separated values. The size of the headers must be less than 80KB. Queue-level headers to override headers of all the tasks in the queue.

The HTTP method to use for the request. When specified, it overrides HttpRequest for the task. Note that if the value is set to HttpMethod the HttpRequest of the task will be ignored at execution time.

If specified, an OAuth token will be generated and attached as an Authorization header in the HTTP request. This type of authorization should generally only be used when calling Google APIs hosted on *.googleapis.com.

If specified, an OIDC token will be generated and attached as an Authorization header in the HTTP request. This type of authorization can be used for many scenarios, including calling Cloud Run, or endpoints where you intend to validate the token yourself.

Uri override. When specified, overrides the execution Uri for all the tasks in the queue.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

OAuth scope to be used for generating OAuth access token. If not specified, "https://www.googleapis.com/auth/cloud-platform" will be used.

Service account email to be used for generating OAuth token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

Audience to be used when generating OIDC token. If not specified, the URI specified in target will be used.

Service account email to be used for generating OIDC token. The service account must be within the same project as the queue. The caller must have iam.serviceAccounts.actAs permission for the service account.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The URI path (e.g., /users/1234). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The query parameters (e.g., qparam1=123&qparam2=456). Default is an empty string.

The number of requests that the queue has dispatched but has not received a reply for yet.

The current maximum number of tasks per second executed by the queue. The maximum value of this variable is controlled by the RateLimits of the Queue. However, this value could be less to avoid overloading the endpoints tasks in the queue are targeting.

The number of tasks that the queue has dispatched and received a reply for during the last minute. This variable counts both successful and non-successful executions.

An estimation of the nearest time in the future where a task in the queue is scheduled to be executed.

An estimation of the number of tasks in the queue, that is, the tasks in the queue that haven't been executed, the tasks in the queue which the queue has dispatched but has not yet received a reply for, and the failed tasks that the queue is retrying.

The number of requests that the queue has dispatched but has not received a reply for yet.

The current maximum number of tasks per second executed by the queue. The maximum value of this variable is controlled by the RateLimits of the Queue. However, this value could be less to avoid overloading the endpoints tasks in the queue are targeting.

The number of tasks that the queue has dispatched and received a reply for during the last minute. This variable counts both successful and non-successful executions.

An estimation of the nearest time in the future where a task in the queue is scheduled to be executed.

An estimation of the number of tasks in the queue, that is, the tasks in the queue that haven't been executed, the tasks in the queue which the queue has dispatched but has not yet received a reply for, and the failed tasks that the queue is retrying.

The number of requests that the queue has dispatched but has not received a reply for yet.

The current maximum number of tasks per second executed by the queue. The maximum value of this variable is controlled by the RateLimits of the Queue. However, this value could be less to avoid overloading the endpoints tasks in the queue are targeting.

The number of tasks that the queue has dispatched and received a reply for during the last minute. This variable counts both successful and non-successful executions.

An estimation of the nearest time in the future where a task in the queue is scheduled to be executed.

An estimation of the number of tasks in the queue, that is, the tasks in the queue that haven't been executed, the tasks in the queue which the queue has dispatched but has not yet received a reply for, and the failed tasks that the queue is retrying.

The number of requests that the queue has dispatched but has not received a reply for yet.

The current maximum number of tasks per second executed by the queue. The maximum value of this variable is controlled by the RateLimits of the Queue. However, this value could be less to avoid overloading the endpoints tasks in the queue are targeting.

The number of tasks that the queue has dispatched and received a reply for during the last minute. This variable counts both successful and non-successful executions.

An estimation of the nearest time in the future where a task in the queue is scheduled to be executed.

An estimation of the number of tasks in the queue, that is, the tasks in the queue that haven't been executed, the tasks in the queue which the queue has dispatched but has not yet received a reply for, and the failed tasks that the queue is retrying.

The number of requests that the queue has dispatched but has not received a reply for yet.

The current maximum number of tasks per second executed by the queue. The maximum value of this variable is controlled by the RateLimits of the Queue. However, this value could be less to avoid overloading the endpoints tasks in the queue are targeting.

The number of tasks that the queue has dispatched and received a reply for during the last minute. This variable counts both successful and non-successful executions.

An estimation of the nearest time in the future where a task in the queue is scheduled to be executed.

An estimation of the number of tasks in the queue, that is, the tasks in the queue that haven't been executed, the tasks in the queue which the queue has dispatched but has not yet received a reply for, and the failed tasks that the queue is retrying.

The number of requests that the queue has dispatched but has not received a reply for yet.

The current maximum number of tasks per second executed by the queue. The maximum value of this variable is controlled by the RateLimits of the Queue. However, this value could be less to avoid overloading the endpoints tasks in the queue are targeting.

The number of tasks that the queue has dispatched and received a reply for during the last minute. This variable counts both successful and non-successful executions.

An estimation of the nearest time in the future where a task in the queue is scheduled to be executed.

An estimation of the number of tasks in the queue, that is, the tasks in the queue that haven't been executed, the tasks in the queue which the queue has dispatched but has not yet received a reply for, and the failed tasks that the queue is retrying.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The max burst size. Max burst size limits how fast tasks in queue are processed when many tasks are in the queue and the rate is high. This field allows the queue to have a high rate so processing starts shortly after a task is enqueued, but still limits resource usage when many tasks are enqueued in a short period of time. The token bucket algorithm is used to control the rate of task dispatches. Each queue has a token bucket that holds tokens, up to the maximum specified by max_burst_size. Each time a task is dispatched, a token is removed from the bucket. Tasks will be dispatched until the queue's bucket runs out of tokens. The bucket will be continuously refilled with new tokens based on max_dispatches_per_second. The default value of max_burst_size is picked by Cloud Tasks based on the value of max_dispatches_per_second. The maximum value of max_burst_size is 500. For App Engine queues that were created or updated using queue.yaml/xml, max_burst_size is equal to bucket_size. If UpdateQueue is called on a queue without explicitly setting a value for max_burst_size, max_burst_size value will get updated if UpdateQueue is updating max_dispatches_per_second.

The maximum number of concurrent tasks that Cloud Tasks allows to be dispatched for this queue. After this threshold has been reached, Cloud Tasks stops dispatching tasks until the number of concurrent requests decreases. If unspecified when the queue is created, Cloud Tasks will pick the default. The maximum allowed value is 5,000. This field is output only for pull queues and always -1, which indicates no limit. No other queue types can have max_concurrent_tasks set to -1. This field has the same meaning as max_concurrent_requests in queue.yaml/xml.

The maximum rate at which tasks are dispatched from this queue. If unspecified when the queue is created, Cloud Tasks will pick the default. * For App Engine queues, the maximum allowed value is 500. * This field is output only for pull queues. In addition to the max_tasks_dispatched_per_second limit, a maximum of 10 QPS of LeaseTasks requests are allowed per pull queue. This field has the same meaning as rate in queue.yaml/xml.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

The maximum number of attempts for a task. Cloud Tasks will attempt the task max_attempts times (that is, if the first attempt fails, then there will be max_attempts - 1 retries). Must be > 0.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_backoff will be truncated to the nearest second. This field has the same meaning as max_backoff_seconds in queue.yaml/xml.

The time between retries will double max_doublings times. A task's retry interval starts at min_backoff, then doubles max_doublings times, then increases linearly, and finally retries at intervals of max_backoff up to max_attempts times. For example, if min_backoff is 10s, max_backoff is 300s, and max_doublings is 3, then the a task will first be retried in 10s. The retry interval will double three times, and then increase linearly by 2^3 * 10s. Finally, the task will retry at intervals of max_backoff until the task has been attempted max_attempts times. Thus, the requests will retry at 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s, .... If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. This field has the same meaning as max_doublings in queue.yaml/xml.

If positive, max_retry_duration specifies the time limit for retrying a failed task, measured from when the task was first attempted. Once max_retry_duration time has passed and the task has been attempted max_attempts times, no further attempts will be made and the task will be deleted. If zero, then the task age is unlimited. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. max_retry_duration will be truncated to the nearest second. This field has the same meaning as task_age_limit in queue.yaml/xml.

A task will be scheduled for retry between min_backoff and max_backoff duration after it fails, if the queue's RetryConfig specifies that the task should be retried. If unspecified when the queue is created, Cloud Tasks will pick the default. This field is output only for pull queues. min_backoff will be truncated to the nearest second. This field has the same meaning as min_backoff_seconds in queue.yaml/xml.

If true, then the number of attempts is unlimited.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.

Host override. When specified, replaces the host part of the task URL. For example, if the task URL is "https://www.google.com," and host value is set to "example.net", the overridden URI will be changed to "https://example.net." Host value cannot be an empty string (INVALID_ARGUMENT).

URI path. When specified, replaces the existing path of the task URL. Setting the path value to an empty string clears the URI path segment.

Port override. When specified, replaces the port part of the task URI. For instance, for a URI http://www.google.com/foo and port=123, the overridden URI becomes http://www.google.com:123/foo. Note that the port value must be a positive integer. Setting the port to 0 (Zero) clears the URI port.

URI Query. When specified, replaces the query part of the task URI. Setting the query value to an empty string clears the URI query segment.

Scheme override. When specified, the task URI scheme is replaced by the provided value (HTTP or HTTPS).

URI Override Enforce Mode When specified, determines the Target UriOverride mode. If not specified, it defaults to ALWAYS.