Skip to content
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

Expose cloudwatch startTime, startTime should be in UTC #36

Merged

Conversation

tbradyRobustWealth
Copy link
Contributor

This PR is intended to give people the ability to pass in a startTime to the toHaveLog method. This gives users of the library more control of the time frame they are searching.

Also, there is a small bug fix in how the default cloudwatch startTime was calculated. It should be in UTC time, rather than local time.

@erezrokah
Copy link
Owner

erezrokah commented Jun 13, 2019

@tbradyRobustWealth thanks for the pr.
Date.now method returns the number of milliseconds elapsed since January 1, 1970 00:00:00 UTC, so I'm not sure where the bug is (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/now).
Using the Date ctor with no arguments yields the same value:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

I'll look over the rest of the pr today

const { filterLogEvents } = require('../utils/cloudwatch');
const { wrapWithRetries } = require('./utils');

const error = new Error('Unknown error');
filterLogEvents.mockReturnValue(Promise.reject(error));

epochDateMinusHours.mockReturnValue(11 * 60 * 60 * 1000);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can remove mocking epochDateMinusHours since you're passing startTime explicitly

}

export const expectedProps = ['region', 'function', 'pattern'];
export const expectedProps = ['region', 'function', 'startTime', 'pattern'];
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If startTime is optional you should not add it to expectedProps (otherwise not passing it will throw an error).
It is not visible in the test "startTime should be defaulted when not passed in" since the common module is mocked thus verifyProps doesn't throw.

If you apply the mock as follows:

jest.mock('../common', () => {
  const actual = jest.requireActual('../common');
  return { ...actual, epochDateMinusHours: jest.fn() };
});

The test will fail

@@ -98,6 +98,7 @@ expect.assertions(1); // makes sure the assertion was called
await expect({
region: 'us-east-1',
function: 'functionName',
startTime: 0 /* optional (millis since epoch in UTC, defaults to now-1 hour) */,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should add this line under chai/README.md as well

const { filterLogEvents } = require('../utils/cloudwatch');

const error = new Error('Unknown error');
filterLogEvents.mockReturnValue(Promise.reject(error));

epochDateMinusHours.mockReturnValue(11 * 60 * 60 * 1000);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can remove mocking epochDateMinusHours since you're passing startTime explicitly


export const epochDateMinusHours = (hours: number) => {
const now = new Date();
return Date.parse(now.toUTCString()) - hoursToMilliseconds(hours);
Copy link
Owner

@erezrokah erezrokah Jun 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different from return Date.now() - hoursToMilliseconds(hours);

Please see the gist here: https://gist.github.com/erezrokah/3fbe380840223a82fde16a16976a0908

The only notable difference I could see is that with Date.parse(now.toUTCString()) the milliseconds data is lost

@erezrokah erezrokah self-requested a review June 13, 2019 13:57
Copy link
Owner

@erezrokah erezrokah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went ahead and created a branch with some changes #37

Let me know if that works for you and I'll merge and publish a new version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants