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 |
paroxp
force-pushed
the
update-aws-packages
branch
2 times, most recently
from
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 :) |
kr8n3r
force-pushed
the
update-aws-packages
branch
3 times, most recently
from
468919c
to
2971fa1
Compare
UPDATE: new date parsing for cloudwatch was done on the output data not input. |
kr8n3r
force-pushed
the
update-aws-packages
branch
2 times, most recently
from
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.
kr8n3r
force-pushed
the
update-aws-packages
branch
from
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 鈿狅笍 馃毃