13.5Retry safely

A request can fail on the network even when obsrvly received it. Then you cannot tell if it worked.

Some APIs accept an idempotency key (a header that makes a repeated request safe). obsrvly does not support an Idempotency-Key header. Use the rules below instead.

Kind of call	Safe to repeat?	What to do
Reads: `Get…`, `List…`	Yes	Repeat as often as you like.
`UpdateMonitor`	Yes	It changes only the fields you send. The same update twice gives the same result.
`SaveStatusPage`	Yes	It replaces the whole page each time.
Deletes	Yes	A second delete answers `not_found`, such as `monitor not found`. Treat that as done.
`AcknowledgeIncident`	Yes	The first acknowledgement stands. No second notice is sent.
`TriggerNow`	Yes	A repeat within 30 seconds is refused, so it cannot start two checks.
Creates: `Create…`	No	A repeat makes a second copy. Check first, as shown below.

Retry a create#

Call ListMonitors (or the matching list call, such as ListAlertChannels). ListMonitors shows the newest monitors first.
Look for your item by its name or URL.
If it is there, the first create worked. Do not create it again.
If it is not there, send the create again.

Secret names are the exception. A team cannot have two secrets with the same name. A repeated CreateSecret answers already_exists (409), secret with this name already exists. That means the first create worked.

Create many URL monitors#

BulkCreateUrlMonitors takes up to 100 URLs per call. The answer has one result per URL. Each result has the url and either a monitor or an error. Send again only the URLs that have an error.

Which errors to retry#

Error	What to do
`unavailable` (503) from a create	Send it again.
`resource_exhausted` (429)	Wait, then send it again (13.4).
`internal` (500), 502 `upstream unreachable`, or a network timeout	You cannot tell if it worked. Check first with a list or get call, then retry.
`invalid_argument`, `failed_precondition`, `permission_denied`, `not_found`, `already_exists`	Do not retry unchanged. Fix the request first.