feat(tracer): add support for capturing DynamoDB DocumentClient

[dreamorosi]

Description of your changes

Customer feedback (link) has pointed out a quirk of instrumenting a DynamoDB DocumentClient, in their words:

One thing that isn't solved here (yet?) is the oddness of working with the X-Ray SDK and DynamoDB DocumentClient. When using DocumentClient with X-Ray, we need to do a workaround as the SDK needs access to the DocumentClient service property, but that's not exposed on the type. Here's how I've solved that problem in the past.

The new implementation attempts to instrument a client normally (reference) first and then, if that fails, it tries to do so by accessing the service property. If both fail it throws as expected.

The advantage of this new mechanism (see example below) is that customers can instrument the DocumentClient in the same way as they do with other AWS SDK clients thus providing a more ergonomic API (& hopefully better DX).

How to verify this change

Before:

import DynamoDB, { DocumentClient } from 'aws-sdk/clients/dynamodb';
import { Tracer } from '@aws-lambda-powertools/tracer';

const tracer = new Tracer({ serviceName: 'paymentCollections' });
const client = new DocumentClient();
tracer.captureAWSClient((client as DocumentClient & { service: DynamoDB }).service); // Explicit typing required in userland

After:

import { DocumentClient } from 'aws-sdk/clients/dynamodb';
import { Tracer } from '@aws-lambda-powertools/tracer';

const tracer = new Tracer({ serviceName: 'paymentCollections' });
const client = new DocumentClient();
tracer.captureAWSClient(client); // Like other AWS SDK v2 clients

// OR const client = tracer.captureAWSClient(new DocumentClient);

Related issues, RFCs

N/A

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• The PR title follows the conventional commit semantics

Breaking change checklist

N/A

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[flochaz]

Could we add an e2e test ?

[dreamorosi]

Could we add an e2e test ?

Good idea, will do and come back to you

[dreamorosi]

Swapped STS calls for DynamoDB calls in all e2e tests for Tracer. Checks are now failing for unrelated reason, need to check why.

[flochaz]

you probably need to rebase first

[dreamorosi]

you probably need to rebase first

You were right, that worked. Thanks a lot, now checks are passing!

[ijemmy]

Great DX improvement :)

btw, I can't find this branch run in E2E workflow. Normally this should be triggerred in "Approve" step but we don't have this for core maintainer.

Is there a way for us to (manually?) run this before merging?

[flochaz]

Great DX improvement :)

btw, I can't find this branch run in E2E workflow. Normally this should be triggerred in "Approve" step but we don't have this for core maintainer.

Is there a way for us to (manually?) run this before merging?

[dreamorosi]

@flochaz @ijemmy ran the workflow, passing result here.
In next PR, where applicable, I'll provide it as part of the checklist.