Files
resolutionflow/backend
Michael Chihlas 87bd0b7c56 WIP: SSE pub/sub for live escalation arrivals (paused for Codex review)
First half of the WebSocket/SSE push slice. Paused mid-flight to hand
the branch to Codex for outside-voice review before stacking more
commits on top. See .ai/HANDOFF.md for the full pause context + what
to look at.

What's here:
- backend/app/core/escalation_bus.py — module-level singleton in-memory
  pub/sub keyed by account_id. asyncio.Queue per subscriber with
  64-event maxsize and drop-on-full semantics. Designed to be swappable
  for Redis pub/sub when Railway scales past single-replica.
- backend/app/api/endpoints/session_handoffs.py — GET
  /api/v1/ai-sessions/escalations/stream SSE endpoint. Auth via
  require_engineer_or_admin. 25s heartbeat. Account-scoped subscribe
  bound to current_user.account_id.
- backend/app/services/handoff_manager.py — dispatch_escalation_notifications
  now publishes a `handoff_created` event to the bus BEFORE the email
  fan-out, in a try/except so a bus failure can't block email delivery.
- backend/tests/test_escalation_bus.py — 7 unit tests, all green
  standalone (0.14s). Cross-tenant isolation, drop-on-full, no-subscribers.
- backend/tests/test_handoff_manager.py — +1 dispatcher integration test
  (publishes to bus, payload shape).
- backend/tests/test_session_handoffs_api.py — +2 endpoint tests (viewer
  blocked, ready event handshake).

[gstack-context]
Decisions:
  - SSE over WebSocket (one-way, browser EventSource semantics, fewer
    moving parts behind Railway proxy)
  - In-memory bus over Redis for v1 pilot (3 MSPs, single replica)
  - Drop-on-full subscriber queue rather than back-pressure publishers
  - Bus publish ahead of email send, both wrapped in try/except so
    neither can break handoff creation
  - Frontend will be a fetch-based ReadableStream reader matching the
    existing streamDocumentation pattern, not native EventSource
    (custom-header auth)
Remaining (post-Codex):
  - Frontend SSE subscription in EscalationQueue.tsx (slide-in,
    reconnect, tab-title flash, prefers-reduced-motion)
  - Magic-moment handoff-context screen
  - Re-run the full backend test suite to verify the SSE +
    dispatcher integration tests (bus units already green standalone)
Tried:
  - Running the full test suite repeatedly without xdist; the per-test
    DROP SCHEMA + recreate fixture made wall-clock prohibitive when
    multiple stale runs collided on the same Postgres test schema.
    Resolution: -n auto next time.
[/gstack-context]

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-04-27 19:29:07 -04:00
..

Troubleshooting Decision Tree - Backend API

FastAPI backend for the Troubleshooting Decision Tree application.

Quick Start

1. Set up Python environment

cd backend
python -m venv venv

# Windows
venv\Scripts\activate

# macOS/Linux
source venv/bin/activate

pip install -r requirements.txt

2. Start PostgreSQL database

Using Docker:

docker-compose up -d

Or install PostgreSQL locally and create a database:

CREATE DATABASE decision_tree;

3. Configure environment

Copy the example env file and update as needed:

cp .env.example .env

4. Run database migrations

alembic upgrade head

5. Start the server

uvicorn app.main:app --reload --host 0.0.0.0 --port 8000

The API will be available at:

API Endpoints

Authentication

  • POST /api/v1/auth/register - Register new user
  • POST /api/v1/auth/login - Login (form data)
  • POST /api/v1/auth/login/json - Login (JSON body)
  • POST /api/v1/auth/refresh - Refresh token
  • GET /api/v1/auth/me - Get current user
  • POST /api/v1/auth/logout - Logout

Trees

  • GET /api/v1/trees - List all trees
  • GET /api/v1/trees/categories - List categories
  • GET /api/v1/trees/search?q=query - Search trees
  • GET /api/v1/trees/{id} - Get specific tree
  • POST /api/v1/trees - Create tree (engineer/admin)
  • PUT /api/v1/trees/{id} - Update tree (engineer/admin)
  • DELETE /api/v1/trees/{id} - Delete tree (admin)

Sessions

  • GET /api/v1/sessions - List user's sessions
  • GET /api/v1/sessions/{id} - Get specific session
  • POST /api/v1/sessions - Start new session
  • PUT /api/v1/sessions/{id} - Update session
  • POST /api/v1/sessions/{id}/complete - Complete session
  • POST /api/v1/sessions/{id}/export - Export session

Development

Create new migration

alembic revision --autogenerate -m "description"

Run migrations

alembic upgrade head

Rollback migration

alembic downgrade -1

Project Structure

backend/
├── alembic/              # Database migrations
│   └── versions/
├── app/
│   ├── api/
│   │   ├── endpoints/    # API route handlers
│   │   ├── deps.py       # Dependencies (auth, etc.)
│   │   └── router.py     # Main router
│   ├── core/
│   │   ├── config.py     # Settings
│   │   ├── database.py   # DB connection
│   │   └── security.py   # JWT, password hashing
│   ├── models/           # SQLAlchemy models
│   ├── schemas/          # Pydantic schemas
│   └── main.py           # FastAPI app
├── tests/
├── alembic.ini
├── docker-compose.yml
├── requirements.txt
└── README.md