Story: Tenancy-based test isolation
Table of Contents
This page documents a story in Sprint 11. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Use tenants as the unit of test isolation: same database, different tenant per test. Faster than tear-down + recreate; closer to how the system actually runs in production.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 11 |
| Now | Completed 2026-02-01. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2026-02-01 |
Acceptance
- C++ tenant_context service in
ores.database. - Per-test tenant provisioning + deprovisioning.
- RLS policies allow the system tenant cross-tenant access.
- CLI gains
--tenant+ORES_TENANT. psqlrcshows the current tenant in the prompt.- Provision + deprovision SQL functions in place.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Use tenancy to isolate tests | DONE | 2026-05-19 | 2026-02-01 | tenant_context C++ service in ores.database; per-test tenant provision + deprovision; RLS policies allow system tenant; –tenant CLI flag + ORES_TENANT env; psqlrc tenant prompt; ores_iam_provision_tenant_fn + ores_iam_deprovision_tenant_fn. |
Decisions
- Tenant-per-test, not database-per-test
- order-of-magnitude faster and more representative of production.
- RLS lets the system tenant cross boundaries
- necessary for admin / provisioning ops; deliberate widening, not a leak.
Out of scope
- Per-test connection pools.
See also
- Tenancy foundation — supplies the schema this story builds on.