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

Add request start and end time to request and response events #673

Merged
merged 1 commit into from
Aug 8, 2019

Conversation

Just-Sieb
Copy link
Contributor

I am working on setting up distributed tracing for work and I am wanting to create spans on our Stripe calls. This change makes it easier to get accurate start and end times for the spans. Plus I think this addition should be beneficial for other people as well.

@ob-stripe
Copy link
Contributor

Hi @Just-Sieb, thanks for the PR!

This looks peaceful to me, but assigning to @rattrayalex-stripe for review.

expect(request.path).to.equal('/v1/charges');
expect(request.request_start_time).to.be.within(
Date.now() - 30000,
Date.now()
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a note that in general, I don't like tests that rely on a real clock and prefer using dependency injection or even mocks/stubs to make the test more deterministic... Not sure if we have an established pattern for doing this in stripe-node. We can probably keep this as-is and revisit if the test ever becomes flaky.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I concur with you on your sentiments on tests like this. I went with this approach because I saw this pattern used for testing the elapsed time so I figured it was what Stripe expects/prefers. Perhaps just a type check of these values to ensure they are a number would be a better option?

Copy link
Contributor

Choose a reason for hiding this comment

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

While I generally also dislike relying on the real clock, I don't think we have delightful mocking available at this time.

That said, we can probably set the starting bound to be a Date.now() set at the top of the test, which should be both more accurate and robust. Similarly, below, in an ideal world we'd check that response.request_end_time is greater than request.request_start_time (which would require adding an onRequest handler).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good suggestions @rattrayalex-stripe, I went ahead and added the request_start_time to the response event as well as that lets me more easily implement your request_end_time greater that request_start_time test as well as improve the elapsed test to not be vulnerable to a bizarre long request. Plus I suspect for some people's usage it will be beneficial for adding logging of the start and end time of any Stripe request. I also made the set lower bound at start of test change. This should be ready for you to review again. Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

Great thinking! Thanks!

Copy link
Contributor

@rattrayalex-stripe rattrayalex-stripe left a comment

Choose a reason for hiding this comment

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

Few small changes requested in the tests, otherwise this looks good! Thanks for taking the time to share this with other users, @Just-Sieb !

response.request_end_time - response.request_start_time
);
expect(response.request_end_time).to.be.within(
lowerBoundStartTime,
Copy link
Contributor

Choose a reason for hiding this comment

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

sorry, tiny nit: probably a bit cleaner to use response.request_start_time here and then remove the expect below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I went ahead and updated. This should be good for you to merge now.

@@ -379,7 +383,16 @@ describe('Flows', function() {
expect(response.path).to.equal('/v1/charges');
expect(response.request_id).to.match(/req_[\w\d]/);
expect(response.status).to.equal(402);
expect(response.elapsed).to.be.within(50, 30000);
expect(response.elapsed).to.equal(
Copy link
Contributor

@rattrayalex-stripe rattrayalex-stripe Aug 8, 2019

Choose a reason for hiding this comment

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

nice!

Copy link
Contributor

@rattrayalex-stripe rattrayalex-stripe left a comment

Choose a reason for hiding this comment

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

Left a tiny nit to clean up the test slightly, but not a requirement to enact it, so approving the PR.

I'll leave this un-merged for a few hours in case you feel like addressing it, and otherwise merge later this afternoon.

Thanks for the contribution, @Just-Sieb !

Copy link
Contributor

@rattrayalex-stripe rattrayalex-stripe left a comment

Choose a reason for hiding this comment

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

Awesome, thanks!

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

Successfully merging this pull request may close these issues.

4 participants