Expand description
Behaviour 63’s guard: did the mock actually HEAR this run?
terraform’s UpCloud provider reaches a mock only through its undocumented
UPCLOUD_DEBUG_API_BASE_URL. A provider release that drops that knob sends
a “mock” apply or destroy to THE ACCOUNT — with whatever token the shell
carried. The guard (lane T13’s ledger, behaviour 63; lane T14 wires it):
- a mock run presents a token minted for THIS run (
mint_token) — never a token of the account, so a provider that ignored the knob is refused by the account with a 401 instead of acting; - before
apply/destroy, a read-only step (aplan) runs with it; require_heardasks the mock’s/mock/hearddoor whether that token’s requests — and aGET /1.3/accountamong them — arrived. Zero is a refusal by name: the provider spoke to somebody, and it was not the mock.
Structs§
- Heard
- What the mock heard from one token.
Functions§
- heard
- Ask the mock at
endpointwhat it heard fromtoken. The account has no such door: asking it is a programming error, refused by name. - mint_
token - A bearer for ONE mock run:
ucat_mock_<pid>_<nanos>. It is not a secret; it is a name the mock can hear. - require_
heard - Refuse
whatunless the mock heardtoken, including aGET /1.3/account.Okcarries what was heard, for the transcript.