Expand description
Mock Suotar: a stand-in for the University of Helsinki Suotar API, and the test/dev control surface around it.
Mounted at /api/v0/mock-suotar only when TEST_MODE and USE_MOCK_SUOTAR_ENDPOINT are both on;
like mock_sisu, the gate is runtime route registration rather than #[cfg]. The mock writes no
database table, and its call log holds unscrubbed fake data that must never feed suotar_api_calls.
Modules§
- api
- The six contract endpoints, one stage boundary at a time.
- commands
- The control command RPC and the three inspection GETs.
- control
- The mock Suotar control surface: test-only routes that are not part of Suotar’s API.
- default_
world - The world installed when nothing has been pushed, and the marker that says which database it belongs to.
- faults
- Addressed faults: what can go wrong that the world’s own data cannot express.
- fixtures
- The fixture identities the credit-registration (Suotar) system tests are built from.
- ids
- Default identifier derivations for the simulated world. Every control upsert may pass an id verbatim instead, and the seed does for anything a spec asserts on.
- logic
- Per-item world-state resolution: pure functions over the working set, with
nowpassed in. - scenarios
- Named scenarios: small compositions of the control primitives, exposed as one command.
- store
- The only Redis-aware part of the mock: key layout, generations, the per-request working set, the write-back pipeline and the call log.
- wire
- The mock’s half of the six contract endpoints: the client’s own request and response types, re-exported so a mock body that the client cannot read is a compile error, plus the shapes and message strings that exist only on the answering side.
- world
- The simulated Sisu world: entities, the submission lifecycle, the world-shaped behaviours, and the per-request working set the endpoints resolve over.
Functions§
- _add_
routes - assert_
enabled - The route cannot be reached with the flags off, so tripping this means the gate itself broke.