A dune-rescue cache must return every kit whose status is open within one depot partition. The API does not know each kit’s item id in advance. Which Cosmos SDK approach is appropriate?
Select an answer to reveal the explanation.
Short Explanation
When you know the filter but not every id, you query—parameterized, through the iterator. Point reads are for “I already know this exact kit,” not “show me all open ones.”
Full Explanation
When a dune-rescue cache must return every kit with status equal to open inside one depot partition and the API does not know each item id, use a parameterized query through the SDK’s query iterator. Filter on status and scope with the partition key when known so the query stays efficient and avoids cross-partition fan-out. Parameterization avoids injection issues and lets the SDK bind values safely.
Issuing a point read with a fabricated id cannot enumerate matching kits; point reads require the real id and partition key for one item. Calling UpsertItem repeatedly does not query—it writes—and will not magically return all open kits. The account-level metadata API returns account/database/container metadata, not filtered item bodies for every container.
Exam caveat: even single-partition queries cost more RUs than point reads; add selective filters and projections, and avoid SELECT * of huge documents when only a few fields are needed. Cross-partition queries are possible but more expensive—prefer including the depot partition key in the WHERE clause. Operational check: run the parameterized query with status = open and the depot partition key, page through the iterator until complete, and compare RU charges against an unfiltered cross-partition scan to confirm scoping works.