---
title: "2026-09-09 vxData API event loop audit"
description: "Audited async FastAPI call chains for synchronous blocking work without modifying the application."
image: "https://docs.virdx.dev/img/virdx-social-card.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.virdx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-09-09 vxData API event loop audit

## Work Done

- Audited `apps/vxdata-api` async FastAPI routes and their service/CRUD call chains in the isolated `/tmp/mono-vxdata-event-loop` worktree.
- Confirmed synchronous MinIO calls and Polars database/parquet work in async routes. The active implementation worktree already converts these route chains to plain `def` handlers so FastAPI runs them in its worker pool.
- Identified synchronous database revision checks and possible Alembic migration work in the async application lifespan as an additional startup-only event-loop blocker.
- Reported exact functions and minimal FastAPI/Starlette-native fixes to the implementing agent. No application files were edited.

## Lessons Learned: Pitfalls

- The worktree already contained uncommitted implementation changes. Auditing both HEAD and the working diff was necessary to distinguish original defects from fixes in progress.
- Broad AST searches flag normal synchronous in-memory operations in async functions. Results still require manual classification to avoid treating small SQL statement construction and model conversion as blocking I/O.

## Lessons Learned: Improvements

- A short vxData API operations note could state that synchronous MinIO, Polars, filesystem, migration, and standard database clients must run in plain FastAPI `def` handlers or an AnyIO/Starlette worker thread.
- Event-loop audits should include the ASGI lifespan and middleware, not only route decorators.

Source: https://docs.virdx.dev/knowledge/inbox/2026-09-09-infrastructure-vxdata-event-loop-audit/index.mdx