Stay organized with collections Save and categorize content based on your preferences.
This page describes how to create tasks and place them in push queues. When you want to process a task, you must create a new task object and place it on a queue. You can explicitly specify the service and handler that process the task, and optionally pass task-specific data along to the handler. You can also fine-tune the configuration for the task, like scheduling a time in the future when it should be executed or limiting the number of times you want the task to be retried if it fails.
This API is supported for first-generation runtimes and can be used when upgrading to corresponding second-generation runtimes. If you are updating to the App Engine Go 1.12+ runtime, refer to the migration guide to learn about your migration options for legacy bundled services. Creating a new taskTo create and enqueue a task, call the taskqueue.Add function.
import("google.golang.org/appengine/taskqueue")
Specifying the worker service
When a task is popped off its queue, the Task Queue service sends it on to a worker service. Every task has a target and a url, which determine what service and handler will ultimately perform the task.
target
The target specifies the service that will receive the HTTP request to perform the task. It is a string that specifies a service/version/instance in any one of the canonical forms. The most often-used forms are:
service
version.service
instance.version.service
The target string is prepended to the domain name of your app. There are three ways to set the target for a task:
Declare the target when you construct the task. You can set the target explicitly when creating the Task object by setting the Host
header:
Include a target
directive when you define a queue in the queue.yaml
, as in the definition of queue-blue
. All tasks added to a queue with a target
will use that target, even if a different target was assigned to the task at construction time.
If no target is specified according to either of the previous two methods, then the task's target is the version of the service that enqueues it. Note that if you enqueue a task from the default service and version in this manner, and the default version changes before the task executes, it will run in the new default version.
url
The url
selects one of the handlers in the target service, which will perform the task.
The url
should match one of the handler URL patterns in the target service. The url
can include query parameters if the method specified in the task is GET
or PULL
. If no url
is specified the default URL /_ah/queue/[QUEUE_NAME]
is used, where [QUEUE_NAME]
is the name of the task's queue.
You can pass data to the handler as query parameters in the task's URL, but only if the method specified in the task is GET
or PULL
.
The NewPOSTTask
function has a positional argument for query_data. The data is usually a dictionary of key-value pairs. If the task's method is POST
or PUT
, the data is added to the payload of the HTTP request. If the method is GET
it is added to the URL as query parameters.
When you create a new task, App Engine assigns the task a unique name by default. However, you can assign your own name to a task by using the name
parameter. An advantage of assigning your own task names is that named tasks are de-duplicated, which means you can use task names to guarantee that a task is only added once. De-duplication continues for 9 days after the task is completed or deleted.
Note that de-duplication logic introduces significant performance overhead, resulting in increased latencies and potentially increased error rates associated with named tasks. These costs can be magnified significantly if task names are sequential, such as with timestamps. So, if you assign your own names, we recommend using a well-distributed prefix for task names, such as a hash of the contents.
If you assign your own names to tasks, note that the maximum name length is 500 characters, and the name can contain uppercase and lowercase letters, numbers underscores, and hyphens.
Enqueuing tasks in Cloud Datastore transactionsYou can enqueue a task as part of a Datastore transaction, such that the task is only enqueued—and guaranteed to be enqueued—if the transaction is committed successfully. Tasks added in a transaction are considered to be a part of it and have the same level of isolation and consistency.
An application cannot insert more than five transactional tasks into task queues during a single transaction. Transactional tasks must not have user-specified names.
The following code sample demonstrates how to insert transactional tasks into a push queue as part of a Datastore transaction:
Using the delayed package instead of a worker serviceSetting up a handler for each distinct task (as described in the previous sections) can be cumbersome, as can serializing and deserializing complex arguments for the task—particularly if you have many diverse but small tasks that you want to run on the queue. The Go SDK includes a package (appengine/delay
) exposing a simple API that allows you to bypass all the work of setting up dedicated task handlers and serializing and deserializing your parameters.
To use the delay
package:
The delay
package serializes your function call and its arguments, then adds it to the task queue. When the task is executed, the delay
package executes the function.
For more information about using the delay
package, refer to its documentation.
By default, push queues use the current namespace as set in the namespace manager at the time the task is created. If your application uses multitenancy, see the Namespaces Go 1.11 API.
What's nextExcept as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-07 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["This document details how to create new tasks and add them to push queues for processing by specifying a target service and handler."],["You can customize task behavior by setting the target service, URL, and data payload for the worker service that will execute the task."],["Tasks can be named for de-duplication purposes, but it's advised to use well-distributed prefixes for custom task names to avoid performance issues."],["Tasks can be enqueued as part of a Datastore transaction, ensuring they are only added if the transaction is successfully committed and guaranteeing consistency."],["The `delay` package offers a simpler alternative to setting up dedicated task handlers by allowing direct serialization and execution of function calls."]]],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4