Story: Give each tenant its own buckets and scope the reaper
Table of Contents
This page documents a story in Sprint 30, carried unfinished from Sprint 28 at close. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
A tenant owns a bucket per data class, the storage service derives the tenant from the bucket, a step service reaches its tenant's buckets with its run token, a run's inputs and outputs are removed at run end with a 24-hour backstop, and the compute reaper acts inside each tenant.
2. Status
| Field | Value |
|---|---|
| State | BACKLOG |
| Parent sprint | Sprint 30 |
| Now | Not yet started. |
| Waiting on | Nothing. |
| Next | Break the story into tasks. |
| Last touched | 2026-11-08 |
3. Acceptance
- A tenant owns an inputs bucket and an outputs bucket, and the platform owns the package and artefact buckets.
- Storage derives the tenant from the bucket, and a step service reaches its tenant's buckets with its run token.
- A run's inputs and outputs are removed when the run ends and its data is in the database, with a 24-hour backstop, and a tenant's data leaves with its buckets.
- The compute reaper acts inside each tenant, so a stale host's work is requeued.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Scope the reaper to each tenant | BACKLOG | The compute service's reap() lists InProgress results and hosts with the service's own system-tenant context. Results are tenant rows and the RLS policy scopes each tenant to its own, so the reaper sees nothing and a stale host's work is never requeued. It needs the same tenant scoping the submit path now uses: act inside each tenant, or iterate the tenants that have work in flight. |
5. Decisions
- Reviewed on 2026-11-08 at sprint 30 start. The story has one open task, the reaper. The goal also names per-tenant buckets, and no task covers them, so confirm those are built or add tasks.