[LeeroyHannigan]

What this fixes

Closes #448.

A Query whose partition key condition uses a non-equality operator, and a legacy KeyConditions
entry using LE or BEGINS_WITH on the partition key, are shapes the engine refuses. Authorization
read no dynamodb:LeadingKeys value for them, so a policy carrying a LeadingKeys condition was
evaluated against no value and every principal saw the shape's ValidationException. A principal
fenced away from the value the request named got ValidationException where DynamoDB answers
AccessDeniedException.

What the service does

Measured against live DynamoDB on 2026-10-21 at 23:14 UTC, us-east-1, on a table with partition key
pk (S) and sort key sk (S), with three principals: the table owner, whose policy carries no
LeadingKeys condition; principal A, allowed dynamodb:* on the table under
ForAllValues:StringEquals dynamodb:LeadingKeys ["alice","galice","10"]; and principal Z, the same
Allow with the single value ["nobody"]. Every request named alice as the partition operand.

request	owner	A, fenced to alice	Z, fenced away
KeyConditionExpression: "pk > :v"	ValidationException, Query key condition not supported	the same ValidationException	AccessDeniedException
KeyConditions: {pk: {ComparisonOperator: LE, AttributeValueList: [alice]}}	the same ValidationException	the same ValidationException	AccessDeniedException
KeyConditions: {pk: {ComparisonOperator: BEGINS_WITH, AttributeValueList: [alice]}}	the same ValidationException	the same ValidationException	AccessDeniedException

A was allowed alice and got the shape error; Z was not and was denied, so the policy was evaluated
against a LeadingKeys value of alice before the shape was refused. The owner's row shows that
binding the key changes nothing for a policy with no condition on it.

Four other refused shapes in the same run returned ValidationException to all three principals: a
syntax error ("pk :: :v"), a condition on the sort key alone ("sk = :s"), an undefined
ExpressionAttributeNames reference ("#p = :v"), and a query on a two-attribute-partition global
secondary index naming one of the two. The first three name no partition operand that can be read.

The change

crates/server/src/leading_keys.rs reads the clauses that name the queried partition attribute.
When one of them is an equality, that equality decides the key, as the engine reads it; when its
value cannot be read (an N value that is not a number, an undefined placeholder) the key stays
absent, as on main, and no other clause's operand is bound in its place. When no clause names the
partition attribute by equality and exactly one clause names it, under <, <=, >, >= or
begins_with, that clause's operand is bound. Two non-equality clauses on the partition attribute
bind nothing. On the legacy path the partition attribute's entry is read when its
ComparisonOperator is one of the service's single-operand operators and its AttributeValueList
holds exactly one value.

crates/core/src/expression/key_condition.rs grows key_condition_clause_operands, which returns
the attribute path and single operand of each clause and whether it is an equality. It runs the
clause loop and the pre-classification checks parse_key_condition already ran, now shared through
parse_clauses, so both functions refuse the same key conditions.

Everything that carried no LeadingKeys before still carries none: an expression that does not
tokenize or parse, an undefined #name or placeholder, a condition naming no partition clause, an
unknown IndexName, a table with no key info. A BETWEEN on the partition key, and legacy BETWEEN
and IN, name more than one value and no record says which the service binds, so they are left as
they are.

Tests

tests/test_fgac_leading_keys.py already sent all seven refused shapes as all three principals and
compared them with the service's rows. It accepted either error code for the three shapes above;
it now requires the code the service returned. The run on main fails those three cases and passes at
this head.

crates/server/src/leading_keys/tests.rs covers the three measured shapes, the operators that follow
the same rule, an N operand (normalized, as on the equality path for a Query), a non-equality
condition on a queried index's own partition key, a name reference that resolves and one that does
not, an unknown placeholder, an unreadable partition equality next to another partition clause, two
non-equality partition clauses, unknown legacy operators, and the shapes that stay absent. One test
asserts that the engine's own parser still refuses every single-clause shape whose operand is now
bound. The two-clause shapes it binds (pk > :v AND sk = :s, pk > :v AND sk < :s) are refused by
the engine when it resolves the partition attribute, which a wire test checks.

tests/test_fgac_leading_keys.py also covers pk = :u AND pk > :v where :u cannot be read, and
checks that alice is not bound in its place.

crates/core/src/expression/key_condition.rs covers the clause list for thirteen expressions and the
refusals it inherits.

Not measured

The three principals of that run were deleted at the end of it and no IAM principal can be created on this
host, so no row covers these: <, <=, >= and begins_with(pk, :v) in a
KeyConditionExpression, legacy NE, LT, GT, GE, CONTAINS and NOT_CONTAINS, and a
non-equality partition condition combined with a sort key condition, two non-equality conditions on
the partition key, and a legacy ComparisonOperator that is not one of the service's operators.
Each single-clause shape names one partition operand, as the three measured shapes do, and is bound
the same way; the two-clause and unknown-operator shapes bind nothing.

The two-attribute-partition index shape is a separate difference in the other direction: the service
returned ValidationException to all three principals and ExtendDB binds the index's first partition
attribute and denies Z. This branch does not change that. The test records it as a divergence rather
than asserting the service's code.

Merges

Of the 66 pull requests open on 2026-10-24, six change a file this branch changes. #484 and #429
conflict in crates/core/src/expression/key_condition.rs: each adds to a region this branch also
adds to, and neither rewrites the other's lines. #484's duplicate-key check belongs at the tail of
parse_clauses, where both callers get it. #399 and #507 (stacked on #399) conflict in the pub use
block of crates/core/src/expression/mod.rs; the merge keeps both sets of exports. #508 merges
clean.

#479 merges clean textually and collides in behaviour. It moves the refusal of a key condition with no
equality out of parse_key_condition into KeyCondition::refuse_without_hash_equality, which the
engine calls with the key schema. On the merged tree this fix still binds alice for pk > :v, and
two tests need updating: #479's
query_kce_without_a_partition_key_equality_leaves_the_key_undetermined, which asserts no key is
bound for pk > :v, and this branch's assertion that parse_key_condition refuses that shape, which
has to move to the engine's call. Whichever lands second carries both edits.