pikopod mode

pikopod scenario check drives its own requests against a throwaway engine, so your application is never in the loop. A mode is the other half: it arms the scenario’s standing conditions on the sandbox pikopod up is serving, and then your own tests, your own app, or plain curl meet the failure. A mode is set on the sandbox and stays until cleared. Fault windows, the request journal and the recordings cursor are partitioned by the X-Pikopod-Scope request header, so parallel workers that each send a scope share one sandbox and one mode without consuming each other’s times windows. Requests without the header share the unscoped partition. See Scoped, or global. Needs pikopod up.

mode set

pikopod mode set <sandbox> <scenario> [--bind role=operationId]

mode: timeouts (from archetype or pack timeouts)
  armed   latency on GET /charges
point your app at the sandbox and run your own tests; clear it with `pikopod mode clear examplepay`

A scenario whose first step is a request has no standing state and is refused with the reason. --bind overrides a role binding, repeatable.

mode show

pikopod mode show <sandbox>

Prints the standing state, or no mode set.

mode clear

pikopod mode clear <sandbox>

Leaves the standing state and clears every fault on the sandbox.

mode verify

pikopod mode verify <sandbox> [--scope <token>] [--format text|json|junit|githubactions]

After your own tests ran against the sandbox in a mode, checks what they sent against the scenario’s verification steps. It reads the request journal and never arms, seeds, or resets anything. With --scope, only the requests that carried X-Pikopod-Scope: <token> are judged; without it, only the requests that carried no scope. --format junit writes one testsuite for the mode and one testcase per verification step; --format githubactions one ::error per failed step; --format json the full result. See Modes.

scope "worker-1": judging only the requests sent with X-Pikopod-Scope: worker-1
✓ retry_storm — PASSED (3 matcher(s) matched in order)
    PASSED         storm-shape      3 matcher(s) matched in order

✓ retry_storm — PASSED (3 matcher(s) matched in order)
    PASSED         storm-shape      3 matcher(s) matched in order

✗ retry_storm — FAILED (matcher 2 (POST /charges) never matched; scanned 2 of 2 journaled request(s); closest: POST /charges (request 2 of 2) already matched matcher 1; no later request matched)
    FAILED         storm-shape      matcher 2 (POST /charges) never matched; scanned 2 of 2 journaled request(s); closest: POST /charges (request 2 of 2) already matched matcher 1; no later request matched

your client did not do what the scenario expects — exit 1

Exit	Meaning
`0`	Every verification step passed.
`1`	The client did not do what the scenario expects.
`2`	No mode is set, the mode’s scenario has no verification step, or a step could not run.

error: no mode set on examplepay: nothing is armed, so there is nothing to verify against → enter one with `pikopod mode set examplepay <scenario>`, run your tests, then verify → https://github.com/pikopod/pikopod/blob/main/scenarios/README.md

See Modes.

CLI

Interfaces

Schemas

mode set

mode show

mode clear

mode verify

​mode set

​mode show

​mode clear

​mode verify

mode set

mode show

mode clear

mode verify