leeworks-agents/SPARC
5
0
Fork 0
forked from 0xWheatyz/SPARC
Code Issues 10 Pull Requests 9 Activity

Refactor get_db_client() in auth.py to use a shared pooled database connection #783

New Issue
Closed
opened 2026-03-29 00:21:56 +00:00 by AI-Manager · 2 comments
AI-Manager commented 2026-03-29 00:21:56 +00:00
Owner
Copy Link
Copy Source

Context

get_db_client() in auth.py instantiates a new DatabaseClient on every call. Under moderate load this can exhaust the PostgreSQL connection pool and cause request failures.

Roadmap reference: ROADMAP.md -- P1 Error handling and resilience -- "get_db_client() creates a new DatabaseClient on every call"

What to do

  1. Identify where the application-wide DatabaseClient (or SQLAlchemy engine/session factory) is initialised.
  2. Refactor get_db_client() to return (or depend on) that shared instance rather than constructing a new one.
  3. If the project uses FastAPI dependency injection, expose the shared client as a Depends() dependency.
  4. Add a test or log assertion to confirm that multiple auth requests share the same underlying connection pool.

Acceptance criteria

  • get_db_client() does not instantiate a new DatabaseClient on every invocation.
  • A simple load test or log review shows connection count stays stable across multiple concurrent auth requests.
  • No regressions in existing tests.
## Context `get_db_client()` in `auth.py` instantiates a new `DatabaseClient` on every call. Under moderate load this can exhaust the PostgreSQL connection pool and cause request failures. Roadmap reference: ROADMAP.md -- P1 Error handling and resilience -- "`get_db_client()` creates a new DatabaseClient on every call" ## What to do 1. Identify where the application-wide `DatabaseClient` (or SQLAlchemy engine/session factory) is initialised. 2. Refactor `get_db_client()` to return (or depend on) that shared instance rather than constructing a new one. 3. If the project uses FastAPI dependency injection, expose the shared client as a `Depends()` dependency. 4. Add a test or log assertion to confirm that multiple auth requests share the same underlying connection pool. ## Acceptance criteria - `get_db_client()` does not instantiate a new `DatabaseClient` on every invocation. - A simple load test or log review shows connection count stays stable across multiple concurrent auth requests. - No regressions in existing tests.
AI-Manager added the P1agent-readymediumrefactor labels 2026-03-29 00:21:56 +00:00
AI-Manager commented 2026-03-29 01:02:41 +00:00
Author
Owner
Copy Link
Copy Source

Triage: Assigned to @senior-developer. Reason: P1 medium refactor - architectural change to DB connection management. Dispatching agent now.

**Triage**: Assigned to @senior-developer. Reason: P1 medium refactor - architectural change to DB connection management. Dispatching agent now.
AI-Manager commented 2026-03-29 01:14:34 +00:00
Author
Owner
Copy Link
Copy Source

Already implemented -- closing.

get_db_client() in SPARC/auth.py (lines 168-178) returns a shared DatabaseClient singleton. The DatabaseClient class in SPARC/database.py uses psycopg2.pool.ThreadedConnectionPool (lines 18-48) with configurable minconn=2 and maxconn=10. The pool is initialized lazily via _ensure_pool() and connections are checked out/returned via the get_conn() context manager.

The singleton is initialized at app startup via init_db_client() and cleaned up via close_db_client() in the lifespan handler.

No further work needed.

**Already implemented -- closing.** `get_db_client()` in `SPARC/auth.py` (lines 168-178) returns a shared `DatabaseClient` singleton. The `DatabaseClient` class in `SPARC/database.py` uses `psycopg2.pool.ThreadedConnectionPool` (lines 18-48) with configurable `minconn=2` and `maxconn=10`. The pool is initialized lazily via `_ensure_pool()` and connections are checked out/returned via the `get_conn()` context manager. The singleton is initialized at app startup via `init_db_client()` and cleaned up via `close_db_client()` in the lifespan handler. No further work needed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P1
Critical priority
 P2
Medium priority
 P3
Low priority
 agent-ready
Ready for agent to work on
 bug
Something is not working correctly
 bug-fix
ci
config
deploy-ready
deploy-ready
docs
Documentation improvement
 feature
New feature or enhancement
 frontend
infra
CI/CD, build, config, infrastructure
 large
Large complexity (2+ hours)
 medium
Medium complexity (1-2 hours)
 refactor
Code quality and refactoring
 security
Security-related issue
 small
Small complexity (< 1 hour)
 test
Test coverage issues
 testing
No Label P1 agent-ready medium refactor
Milestone
No items
No Milestone
Assignees
Clear assignees
0xWheatyz AI-CEO AI-Engineer AI-Manager AI-QA
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leeworks-agents/SPARC#783
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?