[fabicarvano]

The code-side guardrail for this already shipped (KNOWN_MODEL_DIMENSIONS lookup in embeddings.ts). What is still open is the actual database row for the affected tenant, which was never corrected because DB access was not available in the session that made the code fix.

That part cannot be fixed by a PR against this repo at all — it is deployment-specific data, not code. This PR just documents the exact SELECT/UPDATE needed directly in the known-issues entry, so whoever has DB access for the affected deployment can apply it without re-deriving the root cause from the writeup.

No re-embedding is required: since every insert at the wrong dimension failed outright, nothing was ever successfully written with it — this is a one-row config correction.

[kartikmanimuthu]

Thanks @fabicarvano — this is the right shape for a problem that isn't really a code bug: documenting the exact SQL so whoever has database access can apply it without re-deriving the root cause from the writeup.

Agreed on the framing too: nothing was ever successfully written at the wrong dimension, so this is a one-row config correction rather than a re-embedding job. I verified the columns are Unsupported("vector(1024)") in all three places, so the premise holds.

Three small edits I'd like before merge, all in the documented SQL:

• The UPDATE is broader than the SELECT justifies. The SELECT deliberately catches every provider whose dimension isn't 1024 — including ones that are correct for their own model (the OpenAI-compatible provider defaults to 3072). Forcing embeddingModel = 'amazon.titan-embed-text-v2:0' on each flagged row would silently rewrite a working provider's model, so it's worth saying "confirm the row is Titan before applying" explicitly.
• Add a tenant filter (AND "tenantId" = '<tenant id>') to both statements — on a shared database this otherwise touches every tenant.
• "embeddingDimensions" IS DISTINCT FROM 1024 is one null-safe predicate instead of IS NULL OR != 1024.

Approving — thanks for closing the loop on a data-level issue that a code PR can't fix.