Find a container by held key

The escalation boundaryHTTPSDKCLIDashboardaccumulate_keyssearchByFacetsaccumulateByMetadata

Which bin holds order ORD-9 is one GIN-indexed containment query on the bin rows. No side table tracks membership.

The situation

A customer calls about order ORD-9. Support needs to know which bin it sits in right now, among hundreds of open bins.

The recipe

curl -G https://lt.acme.dev/api/escalations \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode 'role=bin' \
  --data-urlencode 'status=pending' \
  --data-urlencode 'facets={"accumulate_keys":["ORD-9"]}'

const { data } = await lt.escalations.list({
  role: 'bin',
  status: 'pending',
  facets: { accumulate_keys: ['ORD-9'] },
});
const bin = data?.escalations[0];

Every add and remove recomputes metadata.accumulate_keys, the list of keys the container holds. Containment on an array matches any row whose list includes the value.

The guarantee

accumulate_keys is rewritten in the same statement as the add or removal, so the index never lags the container. The reverse question reads from the item’s side: after a reciprocal add, the bag’s own row holds the bin’s id. Facet selectors such as accumulateByMetadata consider only pending rows that carry the accumulator declaration, ordered by priority then age. See Batches and accumulators.

The escalation boundary