With EMBEDDING_PROVIDER=openai, the Firestore vector index does not cover the vectors that get written, so findNearest cannot use it. Both the extension and the kit do this, identically.
|
Extension |
Kit |
| Index dimension |
512 (getDimension(), functions/src/config.ts) |
512 (dimensionFor(), kits/firestore-vector-search/src/export-config.ts) |
| Model |
text-embedding-ada-002 |
text-embedding-ada-002 |
| Vector written |
1536 |
1536 |
Each codebase contradicts itself the same way: the value fed to createIndex says 512, while the OpenAI client is built with dimension: 1536 and ada-002 returns 1536.
The vectors store fine, Firestore's limit is 2048, but querying them fails:
9 FAILED_PRECONDITION: Missing vector index configuration. Please create the required
index with the following gcloud command: gcloud firestore indexes composite create
--project=<project> --collection-group=<collection> --query-scope=COLLECTION
--field-config=vector-config='{"dimension":"1536","flat": "{}"}',field-path=embedding
So the provider embeds correctly and is unqueryable through queryCallable, queryOnWrite or any direct findNearest, unless the user creates a 1536-dimension index by hand. Verified live on a deployed instance.
Fixing it
dimensionFor("openai") / getDimension() should return 1536 so the index matches what ada-002 produces. Because both codebases are affected equally, fixing only the kit would introduce a parity divergence, so this wants fixing in both, or a deliberate decision to lead with one.
Two things any fix has to handle:
- Existing 512 indexes are not replaced.
createIndex decides an index already exists by matching the collection name and the field path only, never the dimension, so an instance that already created the 512 index keeps it and creation is skipped. A fix needs a migration note telling users to delete the old index first, or the existence check has to compare dimensions too. Note the second option would also silently rebuild any drifted index on every install.
- The extension persists the dimension. The extension writes
dimension into its metadata document at _<instance id>/index and re-backfills when metadata.dimension !== config.dimension, so changing the value there triggers a full re-embed of the collection, at cost. The kit has no such metadata document today, so it is only a concern for the extension and for any future kit work that restores that gating (see §9d in the ledger).
multimodal has the same shape of self-contradiction (index 512, client 1408) and is covered by #3135.
Related: #3096 restored the ada-002 model, #3105 raised this as a parity question (closed, the kit is in parity), #3163 attempted a kit-only fix (closed as out of parity).
With
EMBEDDING_PROVIDER=openai, the Firestore vector index does not cover the vectors that get written, sofindNearestcannot use it. Both the extension and the kit do this, identically.getDimension(),functions/src/config.ts)dimensionFor(),kits/firestore-vector-search/src/export-config.ts)text-embedding-ada-002text-embedding-ada-002Each codebase contradicts itself the same way: the value fed to
createIndexsays 512, while the OpenAI client is built withdimension: 1536and ada-002 returns 1536.The vectors store fine, Firestore's limit is 2048, but querying them fails:
So the provider embeds correctly and is unqueryable through
queryCallable,queryOnWriteor any directfindNearest, unless the user creates a 1536-dimension index by hand. Verified live on a deployed instance.Fixing it
dimensionFor("openai")/getDimension()should return 1536 so the index matches what ada-002 produces. Because both codebases are affected equally, fixing only the kit would introduce a parity divergence, so this wants fixing in both, or a deliberate decision to lead with one.Two things any fix has to handle:
createIndexdecides an index already exists by matching the collection name and the field path only, never the dimension, so an instance that already created the 512 index keeps it and creation is skipped. A fix needs a migration note telling users to delete the old index first, or the existence check has to compare dimensions too. Note the second option would also silently rebuild any drifted index on every install.dimensioninto its metadata document at_<instance id>/indexand re-backfills whenmetadata.dimension !== config.dimension, so changing the value there triggers a full re-embed of the collection, at cost. The kit has no such metadata document today, so it is only a concern for the extension and for any future kit work that restores that gating (see §9d in the ledger).multimodalhas the same shape of self-contradiction (index 512, client 1408) and is covered by #3135.Related: #3096 restored the ada-002 model, #3105 raised this as a parity question (closed, the kit is in parity), #3163 attempted a kit-only fix (closed as out of parity).