SearchConditionExpression must be provided when SearchSchema has a HASH key

TL;DR — der Vektorindex wurde mit einem HASH-Search-Schema-Attribut angelegt, was einen Partitionsfilter verpflichtend macht. Jeder SearchVectors-Call muss genau einen Wert dafür mit einer Equality-Bedingung pinnen; einen "search all partitions"-Modus gibt es nicht.

Was es bedeutet

ValidationException: SearchConditionExpression must be provided when SearchSchema has a HASH key

Das ist die wörtliche Service-Response, die wir in us-east-1 eingefangen haben, indem wir die Bedingung gegen einen Index mit definiertem HASH-Element weggelassen haben. Die Entscheidung fiel bei der Index-Erstellung: ein HASH-Key partitioniert den Index, und von da an ist jede Suche auf genau einen Partitionswert gescoped.

Warum es passiert

• Die Bedingung fehlt komplett — der häufigste Fall, wenn Code, der gegen einen schemalosen Index geschrieben wurde, auf einen mit HASH-Key gerichtet wird.
• Die Expression pinnt das HASH-Attribut nicht — nur auf ein INLINE_FILTER-Attribut zu filtern erfüllt die Anforderung nicht.
• Die Expression nutzt etwas anderes als Equality — SearchConditionExpression akzeptiert nur =, also failt auch ein begins_with oder IN auf dem Partitionsattribut.

So behebst du es

Ergänze die Bedingung und pinne einen Wert:

aws dynamodb search-vectors \
  --table-name SupportTickets \
  --index-name TicketEmbeddings \
  --search-vector file://query-vector.json \
  --top-k 10 \
  --search-condition-expression "product = :p" \
  --expression-attribute-values '{":p": {"S": "checkout"}}'

Braucht dein Access Pattern wirklich eine partitionsübergreifende Suche, muss der Index ohne HASH-Element angelegt werden — das Search-Schema ist immutable, das heißt also ein neuer Index. Und behandle den Key als Routing-Entscheidung, nicht als Security-Grenze: Fine-grained Access Control gilt nicht für SearchVectors.

Verwandte Themen

Was dir ein HASH-Key bringt (Throughput-Skalierung, günstigere Suchen) und was er kostet: der DynamoDB-Vektorsuche-Guide.