Debug missing tenant filter in SQL in the tenant pgvector index

Do not start with a speculative fix for the tenant pgvector index. Force the failure on purpose, save the before output, then change one cause at a time. Retries are allowed only for transient conditions—not for bad input that will fail forever on vector-db-lab.

def search(tenant_id, version, q):
    if not tenant_id: raise ValueError('tenant_id required')
    if version!='v3': raise ValueError('stale or unknown index_version')
    return ['hours']
try:
    search('cafe-a','v2',[0.1])
except ValueError as e:
    print(e)

Expected evidence: stale or unknown index_version. If you cannot reproduce on demand, you do not yet control the failure mode for vector-db-lab.

After repair, rerun the exact reproduction command. Keep the failing fixture as a regression seed for the observability page. For the tenant-filtered pgvector FAQ index, remember the claim you are restoring: query returns only the requesting tenant's chunks at a pinned index version.

Store a one-command reproduction for: missing tenant filter in SQL, or querying a stale index version silently. The command should use two tenants with overlapping vocabulary FAQ chunks or a minimal mutant of it. Paste the failing output into notes/failure-before.txt (or your shell scrollback as copied text). After the fix, paste notes/failure-after.txt and keep both.

Retries belong only on transient faults. If the failure is bad input, a bad allowlist, or a logic bug in the tenant pgvector index, retrying will amplify cost without repairing trust around replace an in-memory list with a versioned vector index that cannot leak across tenants.

Classify the failure as prevent, detect, contain, or recover—using this lab’s language, not a generic poster. For vector-db-lab, the first fix should usually be detect+prevent at the boundary, because missing tenant filter in SQL, or querying a stale index version silently is cheaper to stop early than to explain in production prose.

At the debugging stage for vector-db-lab, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about two tenants with overlapping vocabulary FAQ chunks that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: in-memory cosine search on the same fixtures.

For this page specifically, success looks like before/after evidence for the characteristic failure while still centering the user decision to replace an in-memory list with a versioned vector index that cannot leak across tenants. If you cannot point to a file, command, or assertion that proves that for the tenant pgvector index, stay on this page instead of advancing.

Glossary: vector database · Glossary: vector index · Cheatsheet: RAG quality

Previous · Next