Summary
SearchService.reindex_vectors() builds entity_ids from find_all and passes the whole list to sync_entity_vectors_batch, which calls find_by_ids(session, entity_ids) — a plain Entity.id.in_(ids) with no chunking.
On Postgres, asyncpg caps bind parameters at 32,767. A project above that fails bm reindex and bm project index outright.
Pre-existing on main. Found while fixing a sibling defect in PR #1440 (#1414).
Why it matters more than the count suggests
bm project index is the command #1414 makes the CLI advertise as the remedy when a project is unindexed. So on a large hosted project, the tool tells the user to run a command that cannot complete — and large projects are exactly where being unindexed hurts most.
PR #1440 fixed an unchunked marker UPDATE on the same code path by reusing the existing VECTOR_HYDRATION_BATCH_SIZE bound. That removes the second failure on this path; this one fires first, so the path is still broken above the cap.
Scope
find_by_ids is shared by many callers, so this is not a one-line change confined to the reindex path — which is why it was flagged rather than folded into #1440 as a last-minute fix.
Worth deciding: whether find_by_ids should chunk internally (fixing every caller at once, at the cost of changing shared behavior) or whether the reindex path should chunk before calling it (narrower, but leaves the same trap for the next caller). The first is more in keeping with how this codebase has been fixing these — the recurring defect has been a rule stated in one place and missing in another.
Note on SQLite
Not reproducible there: the build in use allows 250,000 variables, so the same list is comfortable. That asymmetry is worth a test that asserts the bound structurally rather than relying on a driver to raise, as #1440 did for the marker update.
Summary
SearchService.reindex_vectors()buildsentity_idsfromfind_alland passes the whole list tosync_entity_vectors_batch, which callsfind_by_ids(session, entity_ids)— a plainEntity.id.in_(ids)with no chunking.On Postgres, asyncpg caps bind parameters at 32,767. A project above that fails
bm reindexandbm project indexoutright.Pre-existing on
main. Found while fixing a sibling defect in PR #1440 (#1414).Why it matters more than the count suggests
bm project indexis the command #1414 makes the CLI advertise as the remedy when a project is unindexed. So on a large hosted project, the tool tells the user to run a command that cannot complete — and large projects are exactly where being unindexed hurts most.PR #1440 fixed an unchunked marker
UPDATEon the same code path by reusing the existingVECTOR_HYDRATION_BATCH_SIZEbound. That removes the second failure on this path; this one fires first, so the path is still broken above the cap.Scope
find_by_idsis shared by many callers, so this is not a one-line change confined to the reindex path — which is why it was flagged rather than folded into #1440 as a last-minute fix.Worth deciding: whether
find_by_idsshould chunk internally (fixing every caller at once, at the cost of changing shared behavior) or whether the reindex path should chunk before calling it (narrower, but leaves the same trap for the next caller). The first is more in keeping with how this codebase has been fixing these — the recurring defect has been a rule stated in one place and missing in another.Note on SQLite
Not reproducible there: the build in use allows 250,000 variables, so the same list is comfortable. That asymmetry is worth a test that asserts the bound structurally rather than relying on a driver to raise, as #1440 did for the marker update.