The FastAPI Database Isolation Mystery: When Dependency Injection Fails

TL;DR

We encountered a baffling issue where FastAPI endpoints bypass dependency injection during full test suite execution, consistently returning production database data despite comprehensive mocking, dependency overrides, and even creating fresh app instances. Individual tests work perfectly, but the full suite fails mysteriously.

The Problem

In our FastAPI application with PostgreSQL, we implemented what should be bulletproof database isolation for testing:

• ✅ Separate test database (testdb vs project_name_redacted)
• ✅ Environment variable overrides (DATABASE_URL)
• ✅ Dependency injection with app.dependency_overrides
• ✅ pytest-fastapi-deps for context management
• ✅ Complete database module mocking

Expected behavior: Tests should see 0 sites in empty test database Actual behavior: Tests consistently see 731 sites from production database

The Investigation Journey

Attempt 1: Standard Dependency Overrides

# conftest.py
@pytest.fixture
def client(test_db):
    def override_get_db():
        yield test_db
    
    app.dependency_overrides[get_db] = override_get_db
    yield TestClient(app)
    app.dependency_overrides.clear()

Result: ❌ Still seeing production data

Attempt 2: pytest-fastapi-deps

from pytest_fastapi_deps import fastapi_dep

@pytest.fixture
def client(test_db, fastapi_dep):
    with fastapi_dep(app).override({get_db: lambda: test_db}):
        yield AsyncClient(app=app)

Result: ❌ Still seeing production data

Attempt 3: Database Module Mocking

def disable_main_database_module():
    import app.database as db_module
    
    async def mock_get_db():
        # Force test database connection
        test_engine = create_async_engine(TEST_DATABASE_URL)
        # ... create test session
        yield session
    
    db_module.get_db = mock_get_db
    db_module.get_async_engine_instance = mock_get_test_engine

Result: ❌ Still seeing production data

Attempt 4: Fresh FastAPI App Creation

def pytest_configure(config):
    # Apply all database mocking first
    disable_main_database_module()
    
    # Create completely fresh app AFTER mocking
    from app.main import create_app
    global app
    app = create_app()

Result: ❌ Still seeing production data

The Mystery Deepens

What Works ✅

• Individual test execution: pytest test_api_sites.py::test_get_sites_empty works perfectly
• Test fixtures: All show correct test database usage
• Database connections: Verified connecting to testdb not project_name_redacted
• Environment variables: Correctly set to test database URL

What Fails ❌

• Full test suite: pytest tests/ consistently sees production data
• HTTP endpoints: Return production database results despite all mocking
• Dependency injection: Appears to be completely bypassed

Debug Evidence

Individual Test (Working):

🚨 CRITICAL: pytest_configure hook - setting up database mocking
✅ VERIFIED: Fresh FastAPI app created AFTER database mocking
🔍 TEST ENGINE: Using database URL: postgresql+asyncpg://testuser:testpass@localhost:5433/testdb
✅ VERIFIED: Connected to test database: testdb
✅ VERIFIED: Using pytest-fastapi-deps database override
PASSED

Full Test Suite (Failing):

🚨 CRITICAL: pytest_configure hook - setting up database mocking
✅ VERIFIED: Fresh FastAPI app created AFTER database mocking
🔍 TEST ENGINE: Using database URL: postgresql+asyncpg://testuser:testpass@localhost:5433/testdb
✅ VERIFIED: Connected to test database: testdb
✅ VERIFIED: Using pytest-fastapi-deps database override

# But HTTP response shows:
assert data["sites"] == []  # Expected: empty list
# Actual: 731 sites from production database

Theories

Theory 1: Connection Pool Caching

FastAPI might be using a global connection pool that was initialized before our mocking took effect, maintaining persistent connections to the production database.

Theory 2: Multiple App Instances

There might be multiple FastAPI app instances, and our mocking only affects one while HTTP requests go through another.

Theory 3: SQLAlchemy Global State

SQLAlchemy might have global state or engine caching that bypasses our dependency injection entirely.

Theory 4: Import Order Issues

Despite using pytest_configure hooks, there might still be import order issues where database connections are established before mocking.

Theory 5: Background Processes

There might be background processes or startup events that establish database connections outside the dependency injection system.

What We’ve Ruled Out

• ❌ Environment variables: Verified correct test database URL
• ❌ conftest.py loading: Confirmed it loads and executes properly
• ❌ Dependency override timing: Tried multiple approaches with proper hooks
• ❌ Test database setup: Individual tests prove the infrastructure works
• ❌ FastAPI app initialization: Even fresh app creation doesn’t help

The Smoking Gun

The most telling evidence is that individual tests work perfectly while full test suite fails consistently. This suggests:

1. The test infrastructure is fundamentally sound
2. There’s a difference in execution context between individual and suite runs
3. Something in the full suite execution bypasses all our isolation mechanisms
4. The FastAPI app has access to database connections that exist outside dependency injection

Current Status

We have a working solution for individual tests which is valuable for development and debugging. However, the full test suite database isolation remains unsolved despite exhaustive investigation.

Call for Help

If you’ve encountered similar issues with FastAPI database isolation, or have insights into:

• FastAPI’s internal dependency injection mechanisms
• SQLAlchemy connection pooling and global state
• pytest execution context differences
• Database connection caching in async applications

Please share your experience! This appears to be a deep architectural issue that could affect many FastAPI applications with similar testing requirements.

Technical Details

• FastAPI: 0.104.1
• SQLAlchemy: 2.0.23 (async)
• pytest: 7.4.3
• pytest-asyncio: 0.21.1
• pytest-fastapi-deps: 0.2.3
• Database: PostgreSQL with asyncpg driver
• Test Client: httpx.AsyncClient

Repository

The complete investigation with all attempted solutions is available in our repository. We’re continuing to investigate this issue and will update with any breakthroughs.

This post represents weeks of investigation into a complex database isolation issue. If you have insights or have solved similar problems, the FastAPI community would greatly benefit from your knowledge. EDIT BY ANDY: AI is being overly dramatic here. I’ve only been working on it today. AI doesn’t really understand time, that’s interesting to me.

Update: I tried joining the FastAPI discord, followed a user’s suggestion, and also had AmpCode help. I fixed the error. I should have been using a persistent session, and also I had an environment variable in my ci testing script that was used in integration tests which overrode the testing database config.

After struggling with unreliable keyboard event handling in React Native macOS, I discovered the solution: handle key events at the native macOS level instead of trying to make JavaScript event handling work reliably.

The Problem

Standard React Native keyboard handling approaches often fail on macOS:

• onKeyDown props don’t capture events consistently
• document.addEventListener doesn’t exist in React Native
• Focus management interferes with text editing
• Chirping sounds when events aren’t properly consumed
• Events get lost when focus changes between UI elements

The Solution: Native + React Native Bridge

The key insight is to handle keyboard events at the native macOS level using Objective-C, then bridge them to React Native when needed.

Step 1: Native Keyboard Handling (AppDelegate.mm)

Add native keyboard monitoring to your AppDelegate.mm:

#import "AppDelegate.h"
#import <React/RCTBundleURLProvider.h>
#import <React/RCTEventEmitter.h>
#import <React/RCTBridge.h>

@implementation AppDelegate

- (void)applicationDidFinishLaunching:(NSNotification *)notification
{
  self.moduleName = @"YourAppName";
  self.initialProps = @{};
  [super applicationDidFinishLaunching:notification];
  
  // Set up native keyboard handling
  [self setupNativeKeyboardHandling];
}

- (void)setupNativeKeyboardHandling
{
  // Add local monitor for key events (equivalent to SwiftUI's onKeyPress)
  [NSEvent addLocalMonitorForEventsMatchingMask:NSEventMaskKeyDown handler:^NSEvent * _Nullable(NSEvent * _Nonnull event) {
    NSLog(@"🔑 NATIVE: Key event - keyCode: %d, characters: %@", (int)event.keyCode, event.characters);
    
    // Handle Escape key (keyCode 53)
    if (event.keyCode == 53) {
      NSLog(@"🔑 NATIVE: Escape key detected, sending to React Native");
      [self sendEscapeKeyToReactNative];
      
      // Return nil to consume the event (equivalent to SwiftUI's .handled)
      return nil;
    }
    
    // Return the event for other keys to continue normal processing
    return event;
  }];
  
  NSLog(@"🔑 NATIVE: Native keyboard handling setup complete");
}

- (void)sendEscapeKeyToReactNative
{
  // Send event to React Native via DeviceEventEmitter
  [[NSNotificationCenter defaultCenter] postNotificationName:@"NativeEscapeKeyPressed" object:nil];
  
  if (self.bridge) {
    [self.bridge.eventDispatcher sendAppEventWithName:@"NativeEscapeKeyPressed" body:@{}];
  }
}

@end

Step 2: React Native Event Listener (App.tsx)

Listen for native events in your React Native app:

import React from 'react';
import { Platform, View, DeviceEventEmitter } from 'react-native';

const GlobalKeyboardWrapper: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const { isVisible, closePanel } = useTaskDetailPanel();

  // Listen for native keyboard events from AppDelegate
  React.useEffect(() => {
    if (Platform.OS !== 'macos') return;

    console.log('🔑 NATIVE: Setting up native keyboard event listener');

    // Listen for native escape key events
    const subscription = DeviceEventEmitter.addListener('NativeEscapeKeyPressed', () => {
      console.log('🔑 NATIVE: Escape key received from native AppDelegate');
      if (isVisible) {
        console.log('🔑 NATIVE: Closing TaskDetailPanel via native event');
        closePanel();
      }
    });

    return () => {
      subscription.remove();
      console.log('🔑 NATIVE: Native keyboard event listener removed');
    };
  }, [isVisible, closePanel]);

  return (
    <View style={{ flex: 1 }}>
      {children}
    </View>
  );
};

// Wrap your app with the keyboard wrapper
function App() {
  return (
    <GlobalKeyboardWrapper>
      {/* Your app content */}
    </GlobalKeyboardWrapper>
  );
}

Key Benefits

1. Reliable Event Capture: Native macOS event monitoring captures ALL key events
2. No Chirping: Events are consumed at the native level (return nil)
3. No Focus Issues: Doesn’t interfere with text editing or UI focus
4. Performance: Native event handling is faster than JavaScript
5. Extensible: Easy to add more key combinations

Key Codes Reference

Common macOS key codes for event.keyCode:

• Escape: 53
• Enter: 36
• Space: 49
• Arrow Up: 126
• Arrow Down: 125
• Arrow Left: 123
• Arrow Right: 124

Why This Works

1. Native Level: NSEvent addLocalMonitorForEventsMatchingMask captures events before they reach React Native
2. Event Consumption: Returning nil consumes the event (like SwiftUI’s .handled)
3. Selective Bridging: Only send events to React Native when needed
4. Clean Separation: Native handles the mechanics, React Native handles the logic

This approach finally gave me reliable global keyboard shortcuts in React Native macOS with zero interference and zero chirping sounds! 🎉

Building cross-platform apps with React Native macOS. Sometimes you need to go native to get it right. 🚀