Story: Run the adapter per session
Table of Contents
This page documents a story in Sprint 30. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
The session is what the service knows. One adapter id, one announce, one heartbeat, one demand set, and the feeds it serves. The official adapter reads its transport and its scopes from the catalogue instead of flags, and the simulator appears as one simulated session.
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
- One announce, heartbeat and demand set per session; feeds are scopes inside it.
- The adapter reads endpoint, credential, settings and feed scopes from rows, not command-line flags.
- The simulator runs as one simulated session on the same contract.
- The status read answers session health and the feeds the session serves.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Make the session the adapter identity | BACKLOG | One announce, demand and heartbeat per session; feeds are scopes inside it; the service registry and status key on the session. | ||
| Read the transport from the catalogue | BACKLOG | The official adapter reads the session endpoint, credential and settings and the feed scopes instead of command-line flags. | ||
| Run the simulator as one session | BACKLOG | The simulator announces one simulated session and serves its feeds on the same contract. | ||
| Report session health | BACKLOG | The status read returns session state, heartbeat, served and refused counts, and the feeds the session serves. |
5. Decisions
- The adapter identity is the session name, so the service registry and the status read key on the session.
- Feed health is freshness, not session state; the two are read from different facts.
- The policy and replay feeders remain sessions of built-in adapters.