feat(dynamodb): operation-specific convenience methods for successful request latency metrics

[hsiaoa]

Issue # (if applicable)

Closes #34785.

Reason for this change

The metricSuccessfulRequestLatency() method in TableV2 throws a validation error requiring an "Operation" dimension, but .NET CDK users cannot easily provide this dimension through the available options. This creates a usability issue where .NET developers cannot create SuccessfulRequestLatency metrics for DynamoDB TableV2 instances without complex workarounds.

The root cause is a cross-language compatibility limitation with JSII (JavaScript Interop Interface). While TypeScript users can easily pass complex dimensionsMap objects, .NET users struggle with the JSII translation of nested object structures, making it difficult or impossible to provide the required Operation dimension.

Description of changes

Added 5 JSII-friendly convenience methods to TableV2Base class for creating SuccessfulRequestLatency metrics:

• metricSuccessfulRequestLatencyForGetItem(props?: MetricOptions): Metric
• metricSuccessfulRequestLatencyForPutItem(props?: MetricOptions): Metric
• metricSuccessfulRequestLatencyForQuery(props?: MetricOptions): Metric
• metricSuccessfulRequestLatencyForScan(props?: MetricOptions): Metric
• metricSuccessfulRequestLatencyForOperation(operation: string, props?: MetricOptions): Metric

These methods internally handle the required Operation dimension, providing a clean API for cross-language CDK users. The implementation follows the existing metricXxxForOperation pattern used throughout the CDK DynamoDB module and extends the ITable interface for consistency between Table and TableV2.

Each method internally calls metricSuccessfulRequestLatencyForOperation() with the appropriate operation string, which constructs the proper dimensionsMap with both TableName and Operation dimensions before delegating to the existing metric infrastructure.

Describe any new or updated permissions being added

N/A - No IAM permissions changes. This is a client-side metric creation enhancement that uses existing CloudWatch metric functionality.

Description of how you validated changes

• Unit tests: Added 6 comprehensive unit tests covering all new convenience methods, custom MetricOptions parameter handling, proper dimension validation, and metric properties verification
• Integration tests: Created new integration test integ.dynamodb-v2.alarm-metrics.ts that validates CloudFormation template generation for all 5 new methods, confirming proper AWS::CloudWatch::Alarm resource creation with correct dimensions, namespace, and statistics
• Build verification: Full TypeScript compilation, linting, and JSII compatibility verified
• Cross-language testing: JSII compatibility confirmed for .NET CDK usage through successful CloudFormation template generation
• Regression testing: Existing integration tests confirm no CloudFormation impact and backward compatibility

The integration test generates 6 AWS::CloudWatch::Alarm resources with proper SuccessfulRequestLatency metrics, each containing correct Operation dimensions (GetItem, PutItem, Query, Scan, BatchGetItem) and AWS/DynamoDB namespace configuration.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[pahud]

let's fix them

[jsii-rosetta] [INFO] Loading 36 assemblies
[jsii-rosetta] [INFO] Translating
[jsii-rosetta] [INFO] Preparing dependency closure at /tmp/rosetta4U5BW8 (-vv for more details)
[jsii-rosetta] [INFO] Translating 3241 snippets using 16 workers
[jsii-rosetta] [INFO] Translated 3241 snippets in 681.724 seconds (0.210s/snippet)
[jsii-rosetta] [INFO] Adding translations to /root/.s3buildcache/rosetta-cache.tabl.json
Error: aws-cdk-lib.aws_dynamodb-README-L966.ts:27:5 - error TS2304: Cannot find name 'cloudwatch'.

27 new cloudwatch.Alarm(this, 'GetItemLatencyAlarm', {
       ~~~~~~~~~~
Error: aws-cdk-lib.aws_dynamodb-README-L966.ts:33:5 - error TS2304: Cannot find name 'cloudwatch'.

33 new cloudwatch.Alarm(this, 'QueryLatencyAlarm', {
       ~~~~~~~~~~
Error: aws-cdk-lib.aws_dynamodb-README-L996.ts:13:29 - error TS2304: Cannot find name 'table'.

13 const customLatencyMetric = table.metricSuccessfulRequestLatencyForGetItem({
                               ~~~~~
[jsii-rosetta] [WARN] 3 diagnostics from assemblies with 'strict' mode on (and 75 more non-strict diagnostics)

Pull request has been modified.

[rix0rrr]

This all doesn't need to be in the code that we submit.

[rix0rrr]

These are not necessary anymore if we have the generic one below.

[rix0rrr]

Better yet, this could just be metricSuccessfulRequestLatencyV2, deprecating the old one.

The lack of ability to pass in an operation could be seen as a serious defect that needs to be rectified.

Please tell me we at least had TableName in there already?