Blame - docs/dyn/runtimeconfig_v1beta1.projects.configs.waiters.html - platform/external/python/google-api-python-client

<h1><a href="runtimeconfig_v1beta1.html">Google Cloud RuntimeConfig API</a> . <a href="runtimeconfig_v1beta1.projects.html">projects</a> . <a href="runtimeconfig_v1beta1.projects.configs.html">configs</a> . <a href="runtimeconfig_v1beta1.projects.configs.waiters.html">waiters</a></h1>

76

<h2>Instance Methods</h2>

77

78

<code><a href="#create">create(parent=None, body, x__xgafv=None)</a></code></p>

79

<p class="firstline">Creates a Waiter resource. This operation returns a long-running Operation</p>

80

81

<code><a href="#delete">delete(name, x__xgafv=None)</a></code></p>

82

<p class="firstline">Deletes the Waiter with the specified name.</p>

83

84

<code><a href="#get">get(name, x__xgafv=None)</a></code></p>

85

<p class="firstline">Gets the Waiter resource with the specified name.</p>

86

87

<code><a href="#list">list(parent=None, pageToken=None, x__xgafv=None, pageSize=None)</a></code></p>

88

<p class="firstline">List Waiters within the given RuntimeConfig resource.</p>

89

90

<code><a href="#list_next">list_next(previous_request, previous_response)</a></code></p>

91

<p class="firstline">Retrieves the next page of results.</p>

92

<h3>Method Details</h3>

93

94

<code class="details" id="create">create(parent=None, body, x__xgafv=None)</code>

95

<pre>Creates a Waiter resource. This operation returns a long-running Operation

96

resource which can be polled for completion. However, a Waiter with the

97

given name will exist (and can be retrieved) prior to the resultant

98

Operation completing. If the resultant Operation indicates a failure, the

99

failed Waiter resource will still exist and must be deleted prior to

100

subsequent creation attempts.

101

102

Args:

103

parent: string, The fully-qualified name of the configuration that will own the waiter.

104

Required. Must be a valid configuration name. (required)

105

body: object, The request body. (required)

106

The object takes the form of:

107

108

{ # A Waiter resource waits for some condition within a RuntimeConfig resource

109

# to be met. For example: each node in a distributed system startup process

110

# writes a value to a Variable resource indicating its readiness. A Waiter

111

# configured with the proper `success` condition can be used to wait until

112

# some number of nodes have checked in.

113

# Once created, a Waiter resource is immutable.

114

"name": "A String", # Name of the variable resource.

115

# It has format of

116

# "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}",

117

# Where `project_id` must be a valid Google Cloud project ID, `config_id`

118

# must be a valid RuntimeConfig object and the `waiter_id` must match

119

# RFC 1035 segment specification, and `len(waiter_id)` must be less than

120

# 64 bytes.

121

# The name is assigned by the client, but will be validated on the server

122

# side to adhere to the format.

123

# Name is immutable and cannot be changed. Required.

124

"success": { # A condition that a Waiter resource is waiting for. The set of possible # The success condition. If this condition is met, `done` will be set to

125

# `true` and the `error` value will remain unset. The failure condition

126

# takes precedence over the success condition. If both conditions are met, a

127

# failure will be indicated. Required.

128

# conditions may expand over time.

129

"cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.

130

# under the specified path prefix reaches the specified number.

131

# For example, take the following variables in a RuntimeConfig object:

132

# /foo/variable1 = "value1"

133

# /foo/variable2 = "value2"

134

# /bar/variable3 = "value3"

135

#

136

# These variables would satisfy a Cardinality condition with `path` set to

137

# "/foo" and `number` set to 2, but would not satisify the same condition

138

# with `number` set to 3.

139

"path": "A String", # The root of the variable subtree to monitor. Required.

140

"number": 42, # The number of decendents of `path` that must exist before this condition

141

# is met. Optional; defaults to 1 if not specified.

142

},

143

},

144

"failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to

145

# `true` and the `error` code will be set to ABORTED. The failure condition

146

# takes precedence over the success condition. If both conditions are met, a

147

# failure will be indicated. This value is optional; if no failure condition

148

# is set, the only failure scenario will be a timeout. Optional.

149

# conditions may expand over time.

150

"cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.

151

# under the specified path prefix reaches the specified number.

152

# For example, take the following variables in a RuntimeConfig object:

153

# /foo/variable1 = "value1"

154

# /foo/variable2 = "value2"

155

# /bar/variable3 = "value3"

156

#

157

# These variables would satisfy a Cardinality condition with `path` set to

158

# "/foo" and `number` set to 2, but would not satisify the same condition

159

# with `number` set to 3.

160

"path": "A String", # The root of the variable subtree to monitor. Required.

161

"number": 42, # The number of decendents of `path` that must exist before this condition

162

# is met. Optional; defaults to 1 if not specified.

163

},

164

},

165

"done": True or False, # If the value is `false`, it means the Waiter is still waiting for one of

166

# its conditions to be met.

167

# If true, the Waiter has finished. If the Waiter finished due to a timeout

168

# or failure, `error` will be set. Output only.

169

"timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If

170

# this timeout elapses prior to the success or failure conditions being met,

171

# the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED.

172

# Required.

173

"error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set.

174

# Output only.

175

# programming environments, including REST APIs and RPC APIs. It is used by

176

# [gRPC](https://github.com/grpc). The error model is designed to be:

177

#

178

# - Simple to use and understand for most users

179

# - Flexible enough to meet unexpected needs

#

# # Overview

#

# The `Status` message contains three pieces of data: error code, error message,

184

# and error details. The error code should be an enum value of

185

# google.rpc.Code, but it may accept additional error codes if needed. The

186

# error message should be a developer-facing English message that helps

187

# developers *understand* and *resolve* the error. If a localized user-facing

188

# error message is needed, put the localized message in the error details or

189

# localize it in the client. The optional error details may contain arbitrary

190

# information about the error. There is a predefined set of error detail types

191

# in the package `google.rpc` which can be used for common error conditions.

#

# # Language mapping

#

# The `Status` message is the logical representation of the error model, but it

196

# is not necessarily the actual wire format. When the `Status` message is

197

# exposed in different client libraries and different wire protocols, it can be

198

# mapped differently. For example, it will likely be mapped to some exceptions

199

# in Java, but more likely mapped to some error codes in C.

#

# # Other uses

#

# The error model and the `Status` message can be used in a variety of

204

# environments, either with or without APIs, to provide a

205

# consistent developer experience across different environments.

206

#

207

# Example uses of this error model include:

208

#

209

# - Partial errors. If a service needs to return partial errors to the client,

210

# it may embed the `Status` in the normal response to indicate the partial

211

# errors.

212

#

213

# - Workflow errors. A typical workflow has multiple steps. Each step may

214

# have a `Status` message for error reporting purpose.

215

#

216

# - Batch operations. If a client uses batch request and batch response, the

217

# `Status` message should be used directly inside batch response, one for

218

# each error sub-response.

219

#

220

# - Asynchronous operations. If an API call embeds asynchronous operation

221

# results in its response, the status of those operations should be

222

# represented directly using the `Status` message.

223

#

224

# - Logging. If some API errors are stored in logs, the message `Status` could

225

# be used directly after any stripping needed for security/privacy reasons.

226

"message": "A String", # A developer-facing error message, which should be in English. Any

227

# user-facing error message should be localized and sent in the

228

# google.rpc.Status.details field, or localized by the client.

229

"code": 42, # The status code, which should be an enum value of google.rpc.Code.

230

"details": [ # A list of messages that carry the error details. There will be a

231

# common set of message types for APIs to use.

232

{

233

"a_key": "", # Properties of the object. Contains field @ype with type URL.

},

],

},

"createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout`

238

# to this instant yields the timeout deadline for this Waiter. Output only.

239

}

240

241

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

Returns:

An object of the form:

248

249

{ # This resource represents a long-running operation that is the result of a

250

# network API call.

251

"metadata": { # Service-specific metadata associated with the operation. It typically

252

# contains progress information and common metadata such as create time.

253

# Some services might not provide such metadata. Any method that returns a

254

# long-running operation should document the metadata type, if any.

255

"a_key": "", # Properties of the object. Contains field @ype with type URL.

256

},

257

"done": True or False, # If the value is `false`, it means the operation is still in progress.

258

# If true, the operation is completed, and either `error` or `response` is

259

# available.

260

"response": { # The normal response of the operation in case of success. If the original

261

# method returns no data on success, such as `Delete`, the response is

262

# `google.protobuf.Empty`. If the original method is standard

263

# `Get`/`Create`/`Update`, the response should be the resource. For other

264

# methods, the response should have the type `XxxResponse`, where `Xxx`

265

# is the original method name. For example, if the original method name

266

# is `TakeSnapshot()`, the inferred response type is

267

# `TakeSnapshotResponse`.

268

"a_key": "", # Properties of the object. Contains field @ype with type URL.

269

},

270

"name": "A String", # The server-assigned name, which is only unique within the same service that

271

# originally returns it. If you use the default HTTP mapping, the

272

# `name` should have the format of `operations/some/unique/name`.

273

"error": { # The `Status` type defines a logical error model that is suitable for different # The error result of the operation in case of failure.

274

# programming environments, including REST APIs and RPC APIs. It is used by

275

# [gRPC](https://github.com/grpc). The error model is designed to be:

276

#

277

# - Simple to use and understand for most users

278

# - Flexible enough to meet unexpected needs

#

# # Overview

#

# The `Status` message contains three pieces of data: error code, error message,

283

# and error details. The error code should be an enum value of

284

# google.rpc.Code, but it may accept additional error codes if needed. The

285

# error message should be a developer-facing English message that helps

286

# developers *understand* and *resolve* the error. If a localized user-facing

287

# error message is needed, put the localized message in the error details or

288

# localize it in the client. The optional error details may contain arbitrary

289

# information about the error. There is a predefined set of error detail types

290

# in the package `google.rpc` which can be used for common error conditions.

#

# # Language mapping

#

# The `Status` message is the logical representation of the error model, but it

295

# is not necessarily the actual wire format. When the `Status` message is

296

# exposed in different client libraries and different wire protocols, it can be

297

# mapped differently. For example, it will likely be mapped to some exceptions

298

# in Java, but more likely mapped to some error codes in C.

#

# # Other uses

#

# The error model and the `Status` message can be used in a variety of

303

# environments, either with or without APIs, to provide a

304

# consistent developer experience across different environments.

305

#

306

# Example uses of this error model include:

307

#

308

# - Partial errors. If a service needs to return partial errors to the client,

309

# it may embed the `Status` in the normal response to indicate the partial

310

# errors.

311

#

312

# - Workflow errors. A typical workflow has multiple steps. Each step may

313

# have a `Status` message for error reporting purpose.

314

#

315

# - Batch operations. If a client uses batch request and batch response, the

316

# `Status` message should be used directly inside batch response, one for

317

# each error sub-response.

318

#

319

# - Asynchronous operations. If an API call embeds asynchronous operation

320

# results in its response, the status of those operations should be

321

# represented directly using the `Status` message.

322

#

323

# - Logging. If some API errors are stored in logs, the message `Status` could

324

# be used directly after any stripping needed for security/privacy reasons.

325

"message": "A String", # A developer-facing error message, which should be in English. Any

326

# user-facing error message should be localized and sent in the

327

# google.rpc.Status.details field, or localized by the client.

328

"code": 42, # The status code, which should be an enum value of google.rpc.Code.

329

"details": [ # A list of messages that carry the error details. There will be a

330

# common set of message types for APIs to use.

331

{

332

"a_key": "", # Properties of the object. Contains field @ype with type URL.

},

],

},

}</pre>

</div>

<code class="details" id="delete">delete(name, x__xgafv=None)</code>

341

<pre>Deletes the Waiter with the specified name.

342

343

Args:

344

name: string, The Waiter resource to delete. (required)

345

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

Returns:

An object of the form:

352

353

{ # A generic empty message that you can re-use to avoid defining duplicated

354

# empty messages in your APIs. A typical example is to use it as the request

355

# or the response type of an API method. For instance:

356

#

357

# service Foo {

358

# rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty);

359

# }

360

#

361

# The JSON representation for `Empty` is empty JSON object `{}`.

}</pre>

</div>

<code class="details" id="get">get(name, x__xgafv=None)</code>

367

<pre>Gets the Waiter resource with the specified name.

368

369

Args:

370

name: string, The fully-qualified name of the Waiter resource object to retrieve. (required)

371

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

Returns:

An object of the form:

378

379

{ # A Waiter resource waits for some condition within a RuntimeConfig resource

380

# to be met. For example: each node in a distributed system startup process

381

# writes a value to a Variable resource indicating its readiness. A Waiter

382

# configured with the proper `success` condition can be used to wait until

383

# some number of nodes have checked in.

384

# Once created, a Waiter resource is immutable.

385

"name": "A String", # Name of the variable resource.

386

# It has format of

387

# "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}",

388

# Where `project_id` must be a valid Google Cloud project ID, `config_id`

389

# must be a valid RuntimeConfig object and the `waiter_id` must match

390

# RFC 1035 segment specification, and `len(waiter_id)` must be less than

391

# 64 bytes.

392

# The name is assigned by the client, but will be validated on the server

393

# side to adhere to the format.

394

# Name is immutable and cannot be changed. Required.

395

"success": { # A condition that a Waiter resource is waiting for. The set of possible # The success condition. If this condition is met, `done` will be set to

396

# `true` and the `error` value will remain unset. The failure condition

397

# takes precedence over the success condition. If both conditions are met, a

398

# failure will be indicated. Required.

399

# conditions may expand over time.

400

"cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.

401

# under the specified path prefix reaches the specified number.

402

# For example, take the following variables in a RuntimeConfig object:

403

# /foo/variable1 = "value1"

404

# /foo/variable2 = "value2"

405

# /bar/variable3 = "value3"

406

#

407

# These variables would satisfy a Cardinality condition with `path` set to

408

# "/foo" and `number` set to 2, but would not satisify the same condition

409

# with `number` set to 3.

410

"path": "A String", # The root of the variable subtree to monitor. Required.

411

"number": 42, # The number of decendents of `path` that must exist before this condition

412

# is met. Optional; defaults to 1 if not specified.

413

},

414

},

415

"failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to

416

# `true` and the `error` code will be set to ABORTED. The failure condition

417

# takes precedence over the success condition. If both conditions are met, a

418

# failure will be indicated. This value is optional; if no failure condition

419

# is set, the only failure scenario will be a timeout. Optional.

420

# conditions may expand over time.

421

"cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.

422

# under the specified path prefix reaches the specified number.

423

# For example, take the following variables in a RuntimeConfig object:

424

# /foo/variable1 = "value1"

425

# /foo/variable2 = "value2"

426

# /bar/variable3 = "value3"

427

#

428

# These variables would satisfy a Cardinality condition with `path` set to

429

# "/foo" and `number` set to 2, but would not satisify the same condition

430

# with `number` set to 3.

431

"path": "A String", # The root of the variable subtree to monitor. Required.

432

"number": 42, # The number of decendents of `path` that must exist before this condition

433

# is met. Optional; defaults to 1 if not specified.

434

},

435

},

436

"done": True or False, # If the value is `false`, it means the Waiter is still waiting for one of

437

# its conditions to be met.

438

# If true, the Waiter has finished. If the Waiter finished due to a timeout

439

# or failure, `error` will be set. Output only.

440

"timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If

441

# this timeout elapses prior to the success or failure conditions being met,

442

# the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED.

443

# Required.

444

"error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set.

445

# Output only.

446

# programming environments, including REST APIs and RPC APIs. It is used by

447

# [gRPC](https://github.com/grpc). The error model is designed to be:

448

#

449

# - Simple to use and understand for most users

450

# - Flexible enough to meet unexpected needs

#

# # Overview

#

# The `Status` message contains three pieces of data: error code, error message,

455

# and error details. The error code should be an enum value of

456

# google.rpc.Code, but it may accept additional error codes if needed. The

457

# error message should be a developer-facing English message that helps

458

# developers *understand* and *resolve* the error. If a localized user-facing

459

# error message is needed, put the localized message in the error details or

460

# localize it in the client. The optional error details may contain arbitrary

461

# information about the error. There is a predefined set of error detail types

462

# in the package `google.rpc` which can be used for common error conditions.

#

# # Language mapping

#

# The `Status` message is the logical representation of the error model, but it

467

# is not necessarily the actual wire format. When the `Status` message is

468

# exposed in different client libraries and different wire protocols, it can be

469

# mapped differently. For example, it will likely be mapped to some exceptions

470

# in Java, but more likely mapped to some error codes in C.

#

# # Other uses

#

# The error model and the `Status` message can be used in a variety of

475

# environments, either with or without APIs, to provide a

476

# consistent developer experience across different environments.

477

#

478

# Example uses of this error model include:

479

#

480

# - Partial errors. If a service needs to return partial errors to the client,

481

# it may embed the `Status` in the normal response to indicate the partial

482

# errors.

483

#

484

# - Workflow errors. A typical workflow has multiple steps. Each step may

485

# have a `Status` message for error reporting purpose.

486

#

487

# - Batch operations. If a client uses batch request and batch response, the

488

# `Status` message should be used directly inside batch response, one for

489

# each error sub-response.

490

#

491

# - Asynchronous operations. If an API call embeds asynchronous operation

492

# results in its response, the status of those operations should be

493

# represented directly using the `Status` message.

494

#

495

# - Logging. If some API errors are stored in logs, the message `Status` could

496

# be used directly after any stripping needed for security/privacy reasons.

497

"message": "A String", # A developer-facing error message, which should be in English. Any

498

# user-facing error message should be localized and sent in the

499

# google.rpc.Status.details field, or localized by the client.

500

"code": 42, # The status code, which should be an enum value of google.rpc.Code.

501

"details": [ # A list of messages that carry the error details. There will be a

502

# common set of message types for APIs to use.

503

{

504

"a_key": "", # Properties of the object. Contains field @ype with type URL.

},

],

},

"createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout`

509

# to this instant yields the timeout deadline for this Waiter. Output only.

}</pre>

</div>

<code class="details" id="list">list(parent=None, pageToken=None, x__xgafv=None, pageSize=None)</code>

515

<pre>List Waiters within the given RuntimeConfig resource.

516

517

Args:

518

parent: string, The fully-qualified name of the configuration to list.

519

Required. Must be a valid configuration name. (required)

520

pageToken: string, The token for pagination.

521

x__xgafv: string, V1 error format.

Allowed values

1 - v1 error format

2 - v2 error format

pageSize: integer, List pagination support.

526

The size of the page to return. We may return fewer elements.

527

528

Returns:

529

An object of the form:

530

531

{ # Response for the `ListWaiters()` method.

532

# Order of returned waiter objects is arbitrary.

533

"nextPageToken": "A String", # Pagination support.

534

"waiters": [ # Found waiters in the project.

535

{ # A Waiter resource waits for some condition within a RuntimeConfig resource

536

# to be met. For example: each node in a distributed system startup process

537

# writes a value to a Variable resource indicating its readiness. A Waiter

538

# configured with the proper `success` condition can be used to wait until

539

# some number of nodes have checked in.

540

# Once created, a Waiter resource is immutable.

541

"name": "A String", # Name of the variable resource.

542

# It has format of

543

# "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}",

544

# Where `project_id` must be a valid Google Cloud project ID, `config_id`

545

# must be a valid RuntimeConfig object and the `waiter_id` must match

546

# RFC 1035 segment specification, and `len(waiter_id)` must be less than

547

# 64 bytes.

548

# The name is assigned by the client, but will be validated on the server

549

# side to adhere to the format.

550

# Name is immutable and cannot be changed. Required.

551

"success": { # A condition that a Waiter resource is waiting for. The set of possible # The success condition. If this condition is met, `done` will be set to

552

# `true` and the `error` value will remain unset. The failure condition

553

# takes precedence over the success condition. If both conditions are met, a

554

# failure will be indicated. Required.

555

# conditions may expand over time.

556

"cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.

557

# under the specified path prefix reaches the specified number.

558

# For example, take the following variables in a RuntimeConfig object:

559

# /foo/variable1 = "value1"

560

# /foo/variable2 = "value2"

561

# /bar/variable3 = "value3"

562

#

563

# These variables would satisfy a Cardinality condition with `path` set to

564

# "/foo" and `number` set to 2, but would not satisify the same condition

565

# with `number` set to 3.

566

"path": "A String", # The root of the variable subtree to monitor. Required.

567

"number": 42, # The number of decendents of `path` that must exist before this condition

568

# is met. Optional; defaults to 1 if not specified.

569

},

570

},

571

"failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to

572

# `true` and the `error` code will be set to ABORTED. The failure condition

573

# takes precedence over the success condition. If both conditions are met, a

574

# failure will be indicated. This value is optional; if no failure condition

575

# is set, the only failure scenario will be a timeout. Optional.

576

# conditions may expand over time.

577

"cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.

578

# under the specified path prefix reaches the specified number.

579

# For example, take the following variables in a RuntimeConfig object:

580

# /foo/variable1 = "value1"

581

# /foo/variable2 = "value2"

582

# /bar/variable3 = "value3"

583

#

584

# These variables would satisfy a Cardinality condition with `path` set to

585

# "/foo" and `number` set to 2, but would not satisify the same condition

586

# with `number` set to 3.

587

"path": "A String", # The root of the variable subtree to monitor. Required.

588

"number": 42, # The number of decendents of `path` that must exist before this condition

589

# is met. Optional; defaults to 1 if not specified.

590

},

591

},

592

"done": True or False, # If the value is `false`, it means the Waiter is still waiting for one of

593

# its conditions to be met.

594

# If true, the Waiter has finished. If the Waiter finished due to a timeout

595

# or failure, `error` will be set. Output only.

596

"timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If

597

# this timeout elapses prior to the success or failure conditions being met,

598

# the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED.

599

# Required.

600

"error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set.

601

# Output only.

602

# programming environments, including REST APIs and RPC APIs. It is used by

603

# [gRPC](https://github.com/grpc). The error model is designed to be:

604

#

605

# - Simple to use and understand for most users

606

# - Flexible enough to meet unexpected needs

#

# # Overview

#

# The `Status` message contains three pieces of data: error code, error message,

611

# and error details. The error code should be an enum value of

612

# google.rpc.Code, but it may accept additional error codes if needed. The

613

# error message should be a developer-facing English message that helps

614

# developers *understand* and *resolve* the error. If a localized user-facing

615

# error message is needed, put the localized message in the error details or

616

# localize it in the client. The optional error details may contain arbitrary

617

# information about the error. There is a predefined set of error detail types

618

# in the package `google.rpc` which can be used for common error conditions.

#

# # Language mapping

#

# The `Status` message is the logical representation of the error model, but it

623

# is not necessarily the actual wire format. When the `Status` message is

624

# exposed in different client libraries and different wire protocols, it can be

625

# mapped differently. For example, it will likely be mapped to some exceptions

626

# in Java, but more likely mapped to some error codes in C.

#

# # Other uses

#

# The error model and the `Status` message can be used in a variety of

631

# environments, either with or without APIs, to provide a

632

# consistent developer experience across different environments.

633

#

634

# Example uses of this error model include:

635

#

636

# - Partial errors. If a service needs to return partial errors to the client,

637

# it may embed the `Status` in the normal response to indicate the partial

638

# errors.

639

#

640

# - Workflow errors. A typical workflow has multiple steps. Each step may

641

# have a `Status` message for error reporting purpose.

642

#

643

# - Batch operations. If a client uses batch request and batch response, the

644

# `Status` message should be used directly inside batch response, one for

645

# each error sub-response.

646

#

647

# - Asynchronous operations. If an API call embeds asynchronous operation

648

# results in its response, the status of those operations should be

649

# represented directly using the `Status` message.

650

#

651

# - Logging. If some API errors are stored in logs, the message `Status` could

652

# be used directly after any stripping needed for security/privacy reasons.

653

"message": "A String", # A developer-facing error message, which should be in English. Any

654

# user-facing error message should be localized and sent in the

655

# google.rpc.Status.details field, or localized by the client.

656

"code": 42, # The status code, which should be an enum value of google.rpc.Code.

657

"details": [ # A list of messages that carry the error details. There will be a

658

# common set of message types for APIs to use.

659

{

660

"a_key": "", # Properties of the object. Contains field @ype with type URL.

},

],

},

"createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout`

665

# to this instant yields the timeout deadline for this Waiter. Output only.

},

],

}</pre>

</div>

<code class="details" id="list_next">list_next(previous_request, previous_response)</code>

673

<pre>Retrieves the next page of results.

674

675

Args:

676

previous_request: The request for the previous page. (required)

677

previous_response: The response from the request for the previous page. (required)

678

679

Returns:

680

A request object that you can call 'execute()' on to request the next

681

page. Returns None if there are no more items in the collection.

</pre>

</div>

</body></html>