Operation versions, tiers, health and repairs

See how an operation picks a tier per call, how health moves from ok to degraded or broken, how repairs make new versions, and how to approve or roll back one.

Updated

An operation keeps versions, tracks its health and repairs itself when the site changes. This guide explains tiers, health, repairs and versions.

Tiers

A call starts at the cheapest tier that can work. It moves up only when the site blocks it. The tier in the response says which tier answered.

TierWhat runs the call
1, plain HTTPWayfern sends the learned request itself, with no browser and no cookies.
2, warm browserA browser page already open on the site sends the request with the anonymous cookies the site set there. The page stays open 5 minutes after its last use.
3, runs the pageA fresh browser page opens the trigger page with your arguments and reads the matching response.
  • minTier is the lowest tier the operation can use. Learning finds it.
  • A call starts at the higher of minTier and the tier that last worked for that exit.
  • On blocked, the call moves to the next allowed tier. On rate, it waits 0.5 to 3 seconds and tries once more. On drift, it tries tier 3 once. On input or error, it stops.
  • Set options.maxTier to cap a call. With maxTier: 1, a call never uses a browser. A call fails when the operation needs a higher tier than the cap.

Every tier costs the same 1 credit per call that answers.

Health

HealthMeaning
okThe last call or check answered.
degradedA call drifted, a check failed, or a repair waits for approval.
broken3 repairs in a row failed.
unknownNo evidence yet, for example right after a rollback.

A call that ends with blocked, rate, input or error does not change health. When health becomes broken, the project owner gets an email, at most once a day per operation.

When a repair runs

A call whose answer no longer fits the operation ends with reason drift and starts a repair in the background. A failed check, except one that was rate limited, also starts a repair.

A repair learns the page again with the stored examples and validates the result. It keeps the parameters and the output fields and changes only the request.

  • One repair runs at a time per operation.
  • At most 3 repairs start per operation per UTC day.
  • No repair starts while the operation is paused or while a proposed version waits.
  • Repairs are free.

When an operation fails again within 10 minutes after a repair, its calls go straight to tier 3 for 30 minutes.

Versions

Learning creates version 1. Each repair that passes validation creates a new version, or brings back an earlier version with the same template. A version has one of four states:

StateMeaning
activeCalls use this version.
proposedA repair that waits for an owner or admin.
retiredAn earlier version. It can be activated again.
rejectedA repair that was turned down.

The autoRepair setting, on by default, decides what happens to a repair.

  • On: the repair becomes the active version at once, and the old version is retired.
  • Off: the repair is a proposed version and health is degraded. Approval sets health to ok. A rejection keeps the active version and does not change health.

Approve, reject or roll back

Any project member can list versions. Activate and reject need the project owner or an admin. The routes are under /api/v1/projects/PROJECT_ID/operations/OPERATION_ID.

BASE="https://api.wayfern.com/api/v1/projects/$PROJECT_ID/operations/$OPERATION_ID"
AUTH="Authorization: Bearer $WAYFERN_API_TOKEN"

# List versions, newest first.
curl -s "$BASE/versions" -H "$AUTH"

# Approve a proposed repair, or roll back to a retired version.
curl -s -X POST "$BASE/versions/$VERSION_ID/activate" -H "$AUTH"

# Turn down a proposed repair. Calls keep using the active version.
curl -s -X POST "$BASE/versions/$VERSION_ID/reject" -H "$AUTH"

Activating the active version, or rejecting a version that is not proposed, is a 409. A rollback sets health to unknown until the next call or check.

In the dashboard, the operation page has the Versions list and the Repair on its own switch.

Checks and events

A check replays both examples and records the result. Checks are free.

  • Scheduled checks run every 6, 12, 24 or 72 hours, or never, with a default of 24. An owner or admin sets checkIntervalHours with PATCH .../operations/OPERATION_ID.
  • Scheduled checks skip operations not called in the last 14 days.
  • POST .../check runs a check now. Each operation allows 10 a clock hour. Past that, the answer is 429 with Retry-After.

GET .../events lists what happened, newest first: created, call_drift, repair_started, repair_applied, repair_proposed, repair_failed, check_ok, check_failed, rolled_back, approved and rejected. Events are kept 90 days and hold no response bodies or secrets.

import os

import requests

base = f"https://api.wayfern.com/api/v1/projects/{os.environ['PROJECT_ID']}/operations/{os.environ['OPERATION_ID']}"
auth = {"Authorization": f"Bearer {os.environ['WAYFERN_API_TOKEN']}"}

check = requests.post(f"{base}/check", headers=auth, timeout=180)
check.raise_for_status()
print("check:", check.json()["data"])

events = requests.get(f"{base}/events", headers=auth, params={"page": 1, "pageSize": 20}, timeout=60)
events.raise_for_status()
for event in events.json()["data"]["events"]:
    print(event["createdAt"], event["kind"], event["detail"])

See Repair and versions and Tiers in the reference.