-
Notifications
You must be signed in to change notification settings - Fork 154
chore(tracer): cdk examples + e2e tests #347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
For examples, wondering if we shouldn't have more realistic tests, reading at them first made me thought they were e2e tests. I think we should have a more concrete use case using most of the feature of tracer to show the potential (and maybe 3 variations of them : decorator/manual/middleware). But not that much a per feature example ? just wondering ... |
Happy to discuss this offline but please take a look at the e2e tests I've implemented and let me know if that's more similar to what you mean. |
e2e are great ! was just wondering if examples were not too redundant . but fine for now. will open a discussion |
docs/core/tracer.md
Outdated
Tracer has three global settings that can be used to configure its behavior: | ||
|
||
Setting | Description | Environment variable | Constructor parameter | ||
------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------- | ||
**Trace Enabled** | Explicitly enables/disables tracing | `POWERTOOLS_TRACE_ENABLED` | `enabled` | ||
**Capture Responses** | Captures Lambda or method return as metadata | `POWERTOOLS_TRACER_CAPTURE_RESPONSE` | N/A | ||
**Capture Errors** | Captures Lambda or method exception as metadata | `POWERTOOLS_TRACER_CAPTURE_ERROR` | N/A | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this bit has been changed in main, getting started section + settings. How will it look like once you merge?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will resolve the conflict & accept the version on main
since I made this change several days ago before your PR was merged.
import { captureLambdaHandler, Tracer } from '@aws-lambda-powertools/tracer'; | ||
|
||
// Set environment variable to disable capture response | ||
process.env.POWERTOOLS_TRACER_ERROR_RESPONSE = 'false'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: what about provisioning env variables in CDK? I think this is what developers would do in prod
https://docs.aws.amazon.com/cdk/api/v1/docs/@aws-cdk_aws-lambda.Function.html#environment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW happy to address this as part of the prod release milestone, in case you also agree
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import { captureLambdaHandler, Tracer } from '@aws-lambda-powertools/tracer'; | ||
|
||
// Set environment variable to disable capture response | ||
process.env.POWERTOOLS_TRACER_CAPTURE_RESPONSE = 'false'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in 7caeb28, see this comment.
"@aws-lambda-powertools/logger": "^0.2.0-beta.6", | ||
"@aws-lambda-powertools/metrics": "^0.2.0-beta.6", | ||
"@aws-lambda-powertools/tracer": "^0.2.0-beta.6", | ||
"@aws-sdk/client-sts": "^3.43.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the semantic versioning annotation used in this package.json, every time we have a minor or major breaking change like this:
X.Z.X or Z.X.X
We will have to manually update these dependencies numbers. Can we make them more loose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relaxed to get all beta versions (1320cec), my reasoning is that currently we might be bumping up version quite often and might want to include / have reflected these changes in the examples; once we exit beta we'll lock examples only to major releases or similar..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some minor comments, but looks good already!
Description of your changes
NodejsFunction
& invoke it in its own cdk Construct to avoid repetitionTracer
camelCase
) & fixedcaptureLambdaHandler
referencesHow to verify this change
Pull & checkout the branch, then
cdk deploy
the stack & review the resources & traces created.Related issues, RFCs
#332
PR status
Is this ready for review?: YES
Is it a breaking change?: YES
Checklist
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.