Proposed flow for this scenario
- Selected table and Region
- Partition and sort key schema
- Expression-name aliases
- Typed expression values
- Key condition
- Pagination and result interpretation
This flow describes a design to evaluate. Follow the supported console workflow below to practice with local resources. Its scope appears with the controls; no cloud resources are provisioned.
Decision checkpoints
| Choice | Fits when | Watch for |
|---|---|---|
| Correct key condition | The intended request has the required key values. | Moving the partition condition into a filter. |
| Redesign access pattern | The caller cannot supply the existing partition key for the desired request. | Using Scan as an invisible substitute for an intentional query design. |
Read the table schema used by this request
The synthetic LetX table uses tenantId as its string partition key and requestId as its string sort key. A request that treats status as the partition key does not match that table, even if every item contains a status attribute.
Check table identity and Region, then compare names, case and types. A number and a string containing the same digits are different typed values. Read the actual schema rather than relying on an old form or copied example.
Inspect aliases and values separately
An expression-name alias resolves to an attribute name; an expression-value placeholder resolves to a typed value. Verify both maps and the key condition. Missing aliases, the wrong key attribute or incompatible value types have different repairs.
The local explorer supports selected scalar types, base-table Query and a documented limited expression grammar. It requires its supported alias form and does not implement indexes, arbitrary nested expressions or transaction APIs. An unsupported request should not be presented as a live AWS behavior test.
Reproduce a key mismatch and repair it
Create two synthetic jobs under one tenant and another under a different tenant. Attempt the invalid key request, inspect its validation result, then query with tenantId equality and an eligible requestId condition.
Add a filter and a small evaluated-item limit to inspect why returned items and evaluated items can differ. An empty page may still carry a continuation cursor. Use the table console below to inspect the selected Query result and continuation state; it does not test production query performance.
Changed scenario and design consequence
Question: support needs failed exports across every tenant but only has status. Can adding a status filter to one tenant Query solve that request? No. Define the new access pattern and consider an appropriate index or reporting path in real infrastructure.
Do not broaden tenant access merely to make a convenient scan succeed. Preserve authorization and pagination requirements when changing the model. A green local Query validates a selected key relationship, not production capacity, hot-partition behavior or a cost estimate.
Practice the supported console workflow
Sources and scope
Reviewed against these official references. The model’s supported scope appears alongside its controls.
How we review explanations