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.
