vetkit.data-access.query-in-loop.concurrent
One database read is started per item with Promise.all(items.map(...)) (the N+1 query pattern, run concurrently). The page is not slower for short lists, but a long list opens as many queries at once: they queue for the connection pool and add database load proportional to the list size.
Last updated:
Suite: Production readiness
javascript, typescript
One database read is started per item with Promise.all(items.map(...)) (the N+1 query pattern, run concurrently). The page is not slower for short lists, but a long list opens as many queries at once: they queue for the connection pool and add database load proportional to the list size.
Category: DATABASE · Engine rule severity: INFO
How to fix it
Replace the per-item reads with one query for all items (for example findMany({ where: { id: { in: ids } } }), Drizzle inArray(...), Supabase .in('id', ids)) and look the rows up in a Map. If per-item queries are unavoidable, bound the concurrency (for example with p-limit).
References
Source: packages/engine/rules/data-access/javascript.yml.
Generated from shipped rule definitions at build time. Matching is a review signal, not proof of exploitability. “generic” denotes text matching, not complete language or framework coverage. Runtime configuration and available tools affect whether a rule runs.