Repository navigation
A table ARN passed as TableName returns ResourceNotFoundException #442
Description
What ExtendDB does
The data-plane handlers use the TableName field verbatim as the table name. extract_table_name in crates/server/src/request_helpers.rs returns the raw string, and the engine looks up a table whose name is the whole ARN. No such table exists, so the request returns ResourceNotFoundException.
What DynamoDB does
DynamoDB accepts a full table ARN as the TableName parameter and serves the request against the named table. Measured on 2026-10-22: an authorized GetItem whose TableName is arn:aws:dynamodb:<region>:<account>:table/<name> returns the item. For a caller with no policy, the service returns AccessDeniedException naming the table ARN arn:aws:dynamodb:<region>:<account>:table/<name> as the resource.
Effect
A client that passes a table ARN as TableName, which the service accepts, gets ResourceNotFoundException from ExtendDB. The authorization layer already reduces a table ARN to its bare table name for the IAM decision, so the allow or deny decision is correct; only the engine's table resolution rejects the request.
Suggested fix
In the engine's TableName resolution, accept a well-formed table ARN for this deployment and reduce it to the bare table name before the catalog lookup, so the engine resolves the same table the authorization layer does.
Activity
LeeroyHannigan commentedon Oct 23, 2026
Batch and transaction operations have the same gap.
On DynamoDB (measured 2026-10-23 11:12 UTC), a table ARN is accepted as a BatchGetItem
RequestItemskey, a BatchWriteItemRequestItemskey and a TransactGetItemsTableName. BatchGetItem returns the ARN as the key underResponses, in the form the request used.On main at 9d13202 with SQLite, an allow-all user that names the table by its ARN gets ResourceNotFoundException "Requested resource not found" from GetItem, BatchGetItem and TransactGetItems.
Authorization isn't affected. I ran BatchGetItem, BatchWriteItem, TransactGetItems, TransactWriteItems, GetItem, Query and PutItem as a user fenced to one partition with
dynamodb:LeadingKeys, under ForAllValues, ForAnyValue and plain StringEquals, with the bare name and with the ARN. All 42 requests were denied or got ResourceNotFoundException, and the other partition's item wasn't read or changed.The fix needs to resolve the ARN in
RequestItemskeys andTransactItemstable names as well asTableName, and BatchGetItem has to return results under the key the request used.LeeroyHannigan commentedon Oct 25, 2026
#200 implements this: it resolves a table ARN in
TableName, inRequestItemskeys and in transaction members. It treats the ARN's account and region as the caller's, while this issue asks for an ARN of this deployment and #509 refuses another account's resource before the IAM decision, so the two need the same rule before #200 merges.LeeroyHannigan commentedon Nov 10, 2026
The authorization path has the same gap for batch and transaction targets. A BatchGetItem
RequestItemskey and theTableNameof a transactionGetorConditionCheckcan name a table by ARN. For those targets,crates/server/src/request_helpers.rsreads the key info under the ARN string (lines 340 to 351 on main). The catalog does not hold that string, so the code records the target as missing.dynamodb:LeadingKeysis then absent for that target. With #732,dynamodb:Attributesalso holds no key attributes for it, where a GetItem whoseTableNameis the same ARN holds them. The engine answersResourceNotFoundExceptionfrom the same snapshot, so the request reads no item today.The fix for this issue needs to reduce those targets to the bare table name for the key info too. Then authorization and the engine see the same table.