egg/Task_Reporter
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
38c428dc8d2a5f025f9fc234615830155d382284
Task_Reporter/openspec/changes/archive/2025-12-07-optimize-websocket-db-sessions/specs/realtime-messaging/spec.md
egg 599802b818 feat: Add Chat UX improvements with notifications and @mention support 
- Add ActionBar component with expandable toolbar for mobile
- Add @mention functionality with autocomplete dropdown
- Add browser notification system (push, sound, vibration)
- Add NotificationSettings modal for user preferences
- Add mention badges on room list cards
- Add ReportPreview with Markdown rendering and copy/download
- Add message copy functionality with hover actions
- Add backend mentions field to messages with Alembic migration
- Add lots field to rooms, remove templates
- Optimize WebSocket database session handling
- Various UX polish (animations, accessibility)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-08 08:20:37 +08:00

2.7 KiB
Raw Blame History

ADDED Requirements

Requirement: Short-lived Database Sessions for WebSocket

The system SHALL process WebSocket messages using short-lived database sessions that are acquired and released for each individual operation, rather than holding a session for the entire WebSocket connection lifetime.

Scenario: Message creation with short session

  • WHEN a user sends a message via WebSocket
  • THEN the system acquires a database session
  • AND creates the message with proper sequence number
  • AND commits the transaction
  • AND releases the session immediately
  • AND broadcasts the message to room members

Scenario: Concurrent message handling

  • WHEN multiple users send messages simultaneously
  • THEN each message operation uses an independent database session
  • AND sequence numbers are correctly assigned without duplicates
  • AND no connection pool exhaustion occurs

Requirement: Message Sequence Number Integrity

The system SHALL guarantee unique, monotonically increasing sequence numbers per room using database-level locking to prevent race conditions during concurrent message creation.

Scenario: Concurrent sequence assignment

  • WHEN two users send messages to the same room at the exact same time
  • THEN each message receives a unique sequence number
  • AND the sequence numbers are consecutive without gaps or duplicates

Scenario: High concurrency sequence safety

  • WHEN 50+ users send messages to the same room simultaneously
  • THEN all messages receive correct unique sequence numbers
  • AND the operation does not cause deadlocks

Requirement: Configurable Database Connection Pool

The system SHALL support environment variable configuration for database connection pool parameters to optimize for different deployment scales.

Scenario: Custom pool size configuration

  • WHEN the application starts with DB_POOL_SIZE=20 environment variable
  • THEN the connection pool maintains 20 persistent connections

Scenario: Pool overflow configuration

  • WHEN the application starts with DB_MAX_OVERFLOW=30 environment variable
  • THEN the connection pool can expand up to 30 additional connections beyond the pool size

Scenario: Pool timeout configuration

  • WHEN all connections are in use and a new request arrives
  • AND DB_POOL_TIMEOUT=10 is configured
  • THEN the request waits up to 10 seconds for an available connection
  • AND raises an error if no connection becomes available

Scenario: Default configuration

  • WHEN no database pool environment variables are set
  • THEN the system uses production-ready defaults (pool_size=20, max_overflow=30, timeout=10, recycle=1800)