Long-running operations
Work that takes longer than a request, and how to follow it to the end.
Starting, stopping or creating a game server takes longer than one request
should wait. Calls like these return a google.longrunning.Operation straight
away, and you follow it until it is done.
Which calls return one
| Service | Methods |
|---|---|
| Playpute | CreateGameServer, UpdateGameServer, DeleteGameServer, StartGameServer, StopGameServer, RestartGameServer, CreateGameServerSchematic, CreateGameServerGroup, DeleteGameServerGroup |
| Networks | CreateVpc, DeleteVpc — returned already done |
Everything else answers synchronously.
Waiting for one
Poll google.longrunning.Operations/GetOperation with the operation's name
until done is true. The CLI and the Go SDK do this for you.
plany operations wait projects//locations//operations/op_a3f1client.Wait backs off between polls and fills server from the operation's
response. If your context is cancelled it stops watching and says so; the work
itself carries on.
Reading the result
When done is true, exactly one of response and error is set. response is
what the call would have returned had it been synchronous — the created
GameServer, for instance. error is a google.rpc.Status carrying the same
details a synchronous failure would; see Errors.
A server's first start can take minutes while its world is generated, so poll at
an interval that backs off rather than in a tight loop. plany operations wait
and client.Wait already do.
The resource tells you too
You often do not need the operation at all. A game server carries state,
state_message and error itself, and reading it back shows progress the way
the console does — STATE_PROVISIONING, then STATE_STARTING, then
STATE_RUNNING. Watch state for progress and use the operation for the final
answer.
Cancelling
google.longrunning.Operations/CancelOperation asks for work to stop. It is a
request rather than a guarantee: work that is past the point of being reversed
finishes anyway, and the operation then reports how it ended.