mock-upcloud — the UpCloud API 1.3, faithfully wrong.

A real HTTP server that answers UpCloud's 1.3 surface out of a state machine. Point UPCLOUD_API_BASE at it and the real monetize-cloud-impl upcloud plugin, the real gunnar/deploy/upcloud procedure and the real cargo xtask estate verbs talk to it without knowing. Nothing here reaches the network.

The point is the lies, not the happy path

A mock that answers every call correctly proves nothing, because that is not the provider anybody has. Every behaviour below was MEASURED against the live account or is written down in this estate's history (3, 5 and 37 are the exception: verified against Scaleway, not UpCloud — see below), and each one is armable on its own ([faults::Fault]) so a defect can be reproduced on demand instead of waited for.

Rows 39–63 are lane T13's, from BEHAVIOURS-LEDGER.md beside this crate, where every one carries its source. Three rows above are not UpCloud's: 3 and 37 (412 out_of_stock) and 5 ("0 rows + 403") were verified against Scaleway (fr-par-1 2026-09-09; the IAM change 2026-08-26), not UpCloud. Owner ruling 2026-09-21: they are kept as generic cloud-provider faults — relabelled, not removed, because removing them would re-map every storm seed — and they are never to be read as UpCloud behaviour.

Behaviours 35 and 36 exist for ONE caller: private-gunnar-ops's estate::prune_dead_firewalls and the row F38 that proves it. Together with 1 and 5 they are the four ways a 403/404 pair can lie about whether a server is there, and a caller that reads the list, the detail AND the firewall before it drops a state entry is the only caller that survives all four. A stale state naming a server that was re-laid under a NEW uuid — the likeliest reading of 2026-09-20 — needs no fault at all: create the estate, ask about a uuid that was never created, and the mock answers 404 on the server and 403 on its firewall while the list shows the same titles alive.

Two callers, one API

Everything above is the surface monetize-cloud-impl's plugin and gunnar/deploy/upcloud drive. private-holger-ops drives the SAME account through terraform and UpCloudLtd/upcloud 5.44, which carries UPCLOUD_DEBUG_API_BASE_URL — so the real declaration and the real provider can be pointed here too, and holger's twin, which has never been created because creating it costs money, can be laid down for nothing. That door is [tf], and the first thing it proved was about this crate rather than about holger: a device's storage_size was rendered as a STRING here, the official provider's own SDK declares it int, and every terraform server create died on a shape the account cannot send. Behaviour 10's lesson, a second time.

The calibration

Every fault above is a claim that the mock can be wrong in a particular way, and a claim nobody has checked is a claim. [self_check] drives EVERY variant in [Fault::ALL] twice — disarmed and armed — and fails if the two observations are the same, because a fault that changes nothing a caller can see advertises a coverage this crate does not have. mock-upcloud --self-check prints the table and exits non-zero. Behaviour 38 is what it is for: Estate::detach had no path that answered 200 without removing the device, so every sweep driven against this mock passed a test the mock could not fail.

Time

Every duration above is real, and running 100 000 of them at real speed is three years. So the mock keeps a virtual clock ([clock::Clock]) with a speed knob: 1.0 is faithful wall time, 0.0 makes every transition instant, 100.0 is a hundred times quicker. The ORDER and the RELATIVE durations never change — a storage still goes maintenance → maintenance → online, a delete still traverses maintenance, and a client that does not poll still fails. What changes is only how long the harness waits.

This is the reason the mock is a state machine over a clock rather than a table of canned replies: a canned reply cannot be early.

Faults

[faults::Faults] is a set. A fault can be armed by name (deterministic: it fires every time it can) or a seed can be handed in, in which case the fault weather for the whole run is derived from that seed alone. A failing run is replayable from its seed and nothing else — no recording, no capture file. See [rng::SplitMix64]: the generator is thirty lines and in this crate on purpose, because a dependency's PRNG may change its stream between versions and then a seed stops naming a run.

Behaviour 10 was wrong, and the correction is the more useful entry

This crate shipped claiming the API sends no created on storage rows, so a young volume and an old orphan were the same row. That was the brief and the brief was mistaken. MEASURED against the live account 2026-09-20 — two volumes, both endpoints, created present every time:

018a7b17-5698-4aa9-b160-f6a6daea9921
  GET /1.3/storage/private  → "created": "2026-09-20T10:35:18Z"
  GET /1.3/storage/{uuid}   → "created": "2026-09-20T10:35:18Z"
the Resize Backup's detail  → "created": "2026-09-19T21:54:06Z"

A mock stricter than the provider is worse than one that is laxer. This crate wrote that sentence itself, about the virtio hot-plug attach it used to refuse and which manufactured 82 % of a storm's failures. The same mistake, twice, in opposite directions: a lax mock misses a bug, a strict one invents a verdict path the account cannot reach. It is written here rather than quietly fixed because the correction is worth more than the entry was.

What remains true is smaller and still worth having: the Resize Backup carries no product name in its title (behaviour 9), so a TITLE filter is blind to it — and that is what labelled_gunnar in private-gunnar-ops now exists for. The date was never the missing half; the label was.

The storage rows the mock sends carry created because that is MEASURED. The server rows carry it too, which is INFERRED from the same API sending it for storages and has not been measured on its own — marked here rather than presented as fact, and erring toward sending it for the reason above.

What it is NOT

It is not a simulator of UpCloud's billing, its IP transfer market, its network products (routers, gateways, load balancers, object storage), its managed databases or its Kubernetes. It answers the subset this estate drives, listed in [http], and answers 404 with a NOT_IMPLEMENTED envelope naming the path for everything else — loudly, so an unimplemented call can never read as a working one.