reqrespquery

README

Request/Response Sample with Query-Based Responses

This sample demonstrates how to send a request and get a response from a Temporal workflow via a query.

The workflow in this specific example accepts requests to uppercase a string via signal and then provides the response via a query. This means the requester must poll for response via queries.

Running

Follow the below steps to run this sample:

1. You need a Temporal service running. See details in README.md.

2. Run the following command in the background or in another terminal to run the worker:

   go run ./reqrespquery/worker

3. Run the following command to start the workflow:

   go run ./reqrespquery/starter

4. Run the following command to uppercase a string every second:

   go run ./reqrespquery/request

Multiple of those can be run on different terminals to confirm that the processes are independent.

Comparison with activity-based responses

In the reqrespactivity sample, we use activities to send back responses. Here are the pros/cons of this approach compared to activity-based responses:

Pros:

• Query-based responses don't require a worker on the caller side
• Query-based responses do not have to record the response/query in history
• Query-based responses can occur even after the workflow has been terminated

Cons:

• Query-based responses are often slower due to polling instead of pushing
• Query-based responses require the workflow to store the response state explicitly
• Query-based responses cannot know on the workflow side whether a response was received

Explanation of continue-as-new

Workflows cannot have infinitely-sized history and when the event count grows too large, ContinueAsNew can be returned to start a new one atomically. However, in order not to lose any data, signals must be drained and any other futures that need to be reacted to must be completed first. This means there must be a period where there are no signals to drain and no futures to wait on. If signals come in faster than processed or futures wait so long there is no idle period, ContinueAsNew will not happen in a timely manner and history will grow.

Since this sample is a long-running workflow, once the request count reaches a certain size, we perform a ContinueAsNew. To not lose any data, we only send this if there are no in-flight signal requests or executing activities. An executing activity can mean it is busy retrying. Care must be taken designing these systems where they do not receive requests so frequent that they can never have a idle period to return a ContinueAsNew. Signals are usually fast to receive, so they are less of a problem. Waiting on activities (as a response to the request or as a response callback activity) can be a tougher problem. Since we rely on the response of the activity, activity must complete including all retries. Retry policies of these activities should be set balancing the resiliency needs with the need to have a period of idleness at some point.

Documentation

Index

• func UppercaseActivity(ctx context.Context, input string) (string, error)
• func UppercaseWorkflow(ctx workflow.Context) error
• type Request
• type Requester
  • func NewRequester(options RequesterOptions) (*Requester, error)
  • func (r *Requester) RequestUppercase(ctx context.Context, str string) (string, error)
• type RequesterOptions
• type Response

Functions

func UppercaseActivity

func UppercaseActivity(ctx context.Context, input string) (string, error)

UppercaseActivity uppercases the given string.

func UppercaseWorkflow

func UppercaseWorkflow(ctx workflow.Context) error

UppercaseWorkflow is a workflow that accepts requests to uppercase strings via signals and provides responses via query.

The "request" signal accepts a Request.

The "response" query accepts a request ID.

Types

type Request

type Request struct {
	// ID of the request, also set on the response.
	ID string `json:"id"`
	// String to be uppercased.
	Input string `json:"input"`
}

Request is a request to uppercase a string, passed as a signal argument to UppercaseWorkflow.

type Requester

type Requester struct {
	// contains filtered or unexported fields
}

Requester can request uppercasing of strings.

func NewRequester

func NewRequester(options RequesterOptions) (*Requester, error)

NewRequester creates a new Requester for the given options.

func (*Requester) RequestUppercase

func (r *Requester) RequestUppercase(ctx context.Context, str string) (string, error)

RequestUppercase sends a request and returns a response.

type RequesterOptions

type RequesterOptions struct {
	// Client to the Temporal server. Required.
	Client client.Client
	// ID of the workflow listening for signals to uppercase. Required.
	TargetWorkflowID string
	// Frequency of query for response. Default 300ms.
	ResponseQueryInterval time.Duration
	// How long to wait for response. Default 4 seconds.
	ResponseTimeout time.Duration
}

RequesterOptions are options for NewRequester.

type Response

type Response struct {
	ID     string `json:"id"`
	Output string `json:"output"`
	Error  string `json:"error"`
}

Response is a response to a Request. This can be returned in a map from a query or as the parameter of a callback to a response activity.