-
Notifications
You must be signed in to change notification settings - Fork 9
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
Update AWS-SDK packages #1742
Update AWS-SDK packages #1742
Conversation
turns out we have a v2 of the sdk and these two packages are v3, so there might be an API or payload discrepancy |
56b7e02
to
22093ac
Compare
I see what you did here. I was hoping that we could do a deep compare fo two objects with
but the comparison still fails with ( Received: serializes to the same string) so I think this stringify extend is the best option note: i cannot approve my own PR :) |
468919c
to
2971fa1
Compare
UPDATE: new date parsing for cloudwatch was done on the output data not input. |
ac91c9a
to
98c520f
Compare
`@aws-sdk/client-cloudwatch-node` and `@aws-sdk/client-resource-groups-tagging-api-node` have been deprecated and replaced with `@aws-sdk/client-cloudwatch` and `@aws-sdk/client-resource-groups-tagging-api`respectively additionally add aws-sdk types for v3
Former no longer exists
In my belief, these tests have been failing, as the function comparing two inputs is simply comparing two different yet identical objects. It's similar to: ```js console.log({} === {}); ``` Each of those two identical objects, take a different place in memory allocation, making them different. Instead, we're extending the `jest` functionality, to allow us to compare dumb down version of these objects, in its purest stringified form, essentially comparing the two strings together as oppose to memory allocations. ```js console.log(JSON.stringify({}) === JSON.stringify({})); ``` What's confusing to me really, is how this has worked before. And in reality, this is not a fault with the AWS library itself, but rather with `jest` comparisions. But "at this point, I'm too afraid to ask" and instead of performing more insightful investigation, I'm just going to get on with my life.
Running everything at once is perhaps useful on a local machine, but is also very noisy. In its current confugiration, the build step is being run twice. Separating these jobs, should make things easier to look at and determine what went wrong and where are the improvements required.
There is a possibility that the series will poses some invalid dates. We don't want to be dealing with that, as it may produce some bad outcome for the end user, where for instance, a lot of events happened on the Thursday, 1 January 1970 00:00:00, and then few or none events on current timing people actually care about. Arguably, filtering them out could leave the graph empty, but at this point I feel like there other issues we have on hands as oppose to irrational filtering out?
In release 3.30.0 (aws/aws-sdk-js-v3#2737) AWS-SDK put stricter timestamp parsing. Our stub data for cloudwatch metrics was outputing unix timestamp strings, so aws-sdk parser was throwing `TypeError: Invalid RFC-3339 date-time` In 7b1edc2 we updated the `getGappyRandomData` function to return unix timestamp to address Prometheus stub data formats. We don't want to change the output of the `getGappyRandomData` function, so for cloudwatch stub data, we'll: - parse the unixtimestamp string to an integer - convert it to a valid date - format date to RFC-3339 (ISO 8601-ish) format Now AWS-SDK parser is happy.
98c520f
to
69ab664
Compare
What
@aws-sdk/client-cloudwatch-node and @aws-sdk/client-resource-groups-tagging-api-node have been deprecated and replaced with @aws-sdk/client-cloudwatch and @aws-sdk/client-resource-groups-tagging-api respectively
This updated the packages and imports where required
Modular AWS SDK for JavaScript
How to review
Who can review
not @kr8n3r
🚨⚠️ Please do not merge this pull request via the GitHub UI ⚠️ 🚨