Summary
Verify and correct the Redshift reserved-node tag contract used for purchase idempotency. The current code depends on tag operations on a constructed reserved-node ARN, but AWS's documented taggable resource list does not include reserved nodes. Adding IAM actions alone does not establish that this resource/API combination is supported.
Current behavior
At 81f2fc3ac44ce47221682fa1c50dec26e4f24eed, providers/aws/services/redshift/client.go:
scanNodesForToken constructs arn:aws:redshift:<region>:<account>:reservednode:<id> for active/payment-pending nodes and calls nodeHasIdempotencyTag (lines270-286).nodeHasIdempotencyTag calls DescribeTags; any lookup error propagates and causes a tokened purchase to be refused before buying.tagReservedNode uses the same ARN with CreateTags (lines332 and382). A post-purchase tagging error is logged while the successful purchase result is returned. The pre-purchase guard therefore depends on a marker whose supported write/read contract has not been established.
AWS's Redshift tagging guide enumerates supported resource types without reserved nodes. This is a documented-contract gap, not a claim that a live AWS request was executed or rejected. No purchase, tag mutation or credentialed cloud verification was performed.
Steps to verify the gap
- Trace
PurchaseCommitment through findNodeByIdempotencyToken, scanNodesForToken, nodeHasIdempotencyTag and tagReservedNode at the commit above.
- Reconcile the exact ARN and resource type with AWS's current
DescribeTags/CreateTags contract. Establish support from authoritative documentation or separately authorized read-only evidence; do not buy a reservation to test it.
- Exercise the actual pre-purchase path with an existing active node and a nonempty idempotency token, including a tag lookup error. Exercise post-purchase tag failure and a re-drive without permitting a second real purchase.
Expected behavior and proposed fix
Use a supported, durable idempotency mechanism, and make the limits of post-purchase reconciliation explicit. If the tag API cannot support reserved nodes, replace that assumption at its source; do not suppress lookup errors or broaden IAM to imply the feature works. Confirm first that the chosen mechanism survives an interrupted purchase and cannot silently double-buy on retry.
Keep the provider behavior fix separate from PR LeanerCloud/cloud-commitments-cli#2077's six CE/EC2 runtime grants. Its proposed Redshift tag grants are being removed pending this contract verification. Update the related tests in providers/aws/services/redshift/client_test.go with actual error/re-drive shapes, not only happy-path tag mocks.
References and triage
Severity: medium, limited Redshift users; priority P2 pending contract verification. Potential consequences include refusing legitimate tokened purchases or unreliable re-drive deduplication. No observed duplicate purchase is claimed. Effort M; investigate this sprint before adding tag grants or optimizing the tag scan.
Summary
Verify and correct the Redshift reserved-node tag contract used for purchase idempotency. The current code depends on tag operations on a constructed reserved-node ARN, but AWS's documented taggable resource list does not include reserved nodes. Adding IAM actions alone does not establish that this resource/API combination is supported.
Current behavior
At
81f2fc3ac44ce47221682fa1c50dec26e4f24eed,providers/aws/services/redshift/client.go:scanNodesForTokenconstructsarn:aws:redshift:<region>:<account>:reservednode:<id>for active/payment-pending nodes and callsnodeHasIdempotencyTag(lines270-286).nodeHasIdempotencyTagcallsDescribeTags; any lookup error propagates and causes a tokened purchase to be refused before buying.tagReservedNodeuses the same ARN withCreateTags(lines332 and382). A post-purchase tagging error is logged while the successful purchase result is returned. The pre-purchase guard therefore depends on a marker whose supported write/read contract has not been established.AWS's Redshift tagging guide enumerates supported resource types without reserved nodes. This is a documented-contract gap, not a claim that a live AWS request was executed or rejected. No purchase, tag mutation or credentialed cloud verification was performed.
Steps to verify the gap
PurchaseCommitmentthroughfindNodeByIdempotencyToken,scanNodesForToken,nodeHasIdempotencyTagandtagReservedNodeat the commit above.DescribeTags/CreateTagscontract. Establish support from authoritative documentation or separately authorized read-only evidence; do not buy a reservation to test it.Expected behavior and proposed fix
Use a supported, durable idempotency mechanism, and make the limits of post-purchase reconciliation explicit. If the tag API cannot support reserved nodes, replace that assumption at its source; do not suppress lookup errors or broaden IAM to imply the feature works. Confirm first that the chosen mechanism survives an interrupted purchase and cannot silently double-buy on retry.
Keep the provider behavior fix separate from PR LeanerCloud/cloud-commitments-cli#2077's six CE/EC2 runtime grants. Its proposed Redshift tag grants are being removed pending this contract verification. Update the related tests in
providers/aws/services/redshift/client_test.gowith actual error/re-drive shapes, not only happy-path tag mocks.References and triage
ResourceType: "reservednode"optimization must not be implemented without resolving this contract first.Severity: medium, limited Redshift users; priority P2 pending contract verification. Potential consequences include refusing legitimate tokened purchases or unreliable re-drive deduplication. No observed duplicate purchase is claimed. Effort M; investigate this sprint before adding tag grants or optimizing the tag scan.