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

Check if properRoute is found before acting on it #73

Merged
merged 3 commits into from
Mar 8, 2022

Conversation

kdhira
Copy link
Contributor

@kdhira kdhira commented Feb 21, 2022

In the cases where the request route is not matched to any Koa route,
bail out before trying to format the path string.

Issue: #59

In the cases where the request route is not matched to any Koa route,
bail out before trying to format the path string.

Issue: PayU#59
@kdhira kdhira mentioned this pull request Feb 21, 2022
// If proper route is not found, send an undefined route
// The caller is responsible for setting a default "N/A" route in this case
if (!properRoute) {
return undefined;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the _handleResponse method, this will set the route label to 'N/A' though the || operator. Let me know if there is a cleaner solution

@kdhira
Copy link
Contributor Author

kdhira commented Feb 26, 2022

@kobik can you take a look at this?

@kobik
Copy link
Collaborator

kobik commented Feb 26, 2022

Hi @kdhira , thanks for the PR!

I'll have a look tomorrow.

@kdhira
Copy link
Contributor Author

kdhira commented Feb 27, 2022

Thanks @kobik

Let me know if there's any questions or anything you're unsure about. Like I mentioned before, the fix minimally circumvents the NPE which gets the route label working with just 'N/A' for my usecase.

Also I'm hoping that these changes can be released to NPM as a version of prometheus-api-metrics, probably something like 3.2.1 of the package. Is there anything extra I need to do (ie version bumping etc) or is that all handled by you?

Copy link
Collaborator

@kobik kobik left a comment

Choose a reason for hiding this comment

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

Thanks @kdhira.
Is it possible to add a test for this scenario?

package.json Outdated
@@ -1,6 +1,6 @@
{
"name": "prometheus-api-metrics",
"version": "0.0.0",
"version": "3.2.0",
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 found this to be the problem with package-lock.json file, giving me a version difference. I restored the 3.2.0 version to the package.json

Also I had to use Node v15 with the v2 lockfileversion otherwise it would try to restore the v1 config, rewriting most of the package-lock.json

Copy link
Collaborator

@kobik kobik Mar 8, 2022

Choose a reason for hiding this comment

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

the version should remain 0.0.0 as we use semantic-release to generate the next version which sets it in the package.json file as part of the release process

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah okay, thanks for explaining this. This is easy for me to revert, will switch it back

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 have reverted the package version to 0.0.0

@@ -653,6 +653,57 @@ describe('metrics-middleware', () => {
Prometheus.register.clear();
});
});
describe('when using middleware request and path not matched to any specific route', () => {
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 had to spend a little time to understand how the tests were made and what level of things were being tested. So I believe this 1 unit test is sufficient for the code changes I've made. But please advise if there is anything else you request

@kdhira
Copy link
Contributor Author

kdhira commented Mar 1, 2022

Hi @kobik,

I added a unit test for this scenario. Please let me know if anything is wrong. I also have a commit for updating dependencies from npm audit fix.

Copy link
Collaborator

@kobik kobik left a comment

Choose a reason for hiding this comment

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

@kdhira thanks for your PR.

See my comment

@kdhira kdhira force-pushed the fix/#59-catch-unmatched-routes branch from d99901e to f1c554f Compare March 8, 2022 07:28
@kdhira
Copy link
Contributor Author

kdhira commented Mar 8, 2022

Thanks @kobik,

I've seen your comment regarding the package version, and have reverted it. I had this as a separate commit so it was simple for me to just rebase it out.

Let me know if there's anything else I should change :)

@kobik
Copy link
Collaborator

kobik commented Mar 8, 2022

@kdhira, can you also revert the package-lock.json changes?

I'd like to handle them in a separate PR.

@kdhira kdhira force-pushed the fix/#59-catch-unmatched-routes branch from f1c554f to 1ec335e Compare March 8, 2022 07:58
@kdhira
Copy link
Contributor Author

kdhira commented Mar 8, 2022

@kobik, I have dropped my commit that updated dependencies (and doing so reverted the package-lock.json changes I made). Hope this helps!

@kobik
Copy link
Collaborator

kobik commented Mar 8, 2022

Sure, thanks again @kdhira !

kobik
kobik previously approved these changes Mar 8, 2022
@kobik
Copy link
Collaborator

kobik commented Mar 8, 2022

@kdhira it seems like the new test didn't cover our case.

see https://coveralls.io/builds/47157280/source?filename=src%2Fkoa-middleware.js#L99

@kdhira
Copy link
Contributor Author

kdhira commented Mar 8, 2022

Hmm I'll have to look at the test again, but I'm pretty confident that line gets run as the test I made has to resolve the route to use in the metric as 'N/A' somehow (through the || 'N/A' in _handleResponse) ...

@kdhira
Copy link
Contributor Author

kdhira commented Mar 8, 2022

Does the coveralls tool run the unit-tests or the integration tests (or both) to detect coverage?

@kdhira
Copy link
Contributor Author

kdhira commented Mar 8, 2022

Hey @kobik,

I think I have done what I need to ensure coverage. I added an integration test, and updated the test koa-server implementation so that the wildcard endpoint case could be correctly tested.

I also ran npm run integration-tests and after this addition it no longer shows line 99 as being an Uncovered Line.

Should be ready to run the Github workflows again

@kobik
Copy link
Collaborator

kobik commented Mar 8, 2022

you're correct, for some reason it's only collected from integration tests.
you can update the workflow to run nyc npm test instead of running unit and integration separately, which should collect the coverage of both of them.

but also what you did should be fine 👍

@kobik kobik merged commit d11c383 into PayU:master Mar 8, 2022
@github-actions
Copy link

github-actions bot commented Mar 8, 2022

🎉 This PR is included in version 3.2.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@kdhira kdhira deleted the fix/#59-catch-unmatched-routes branch March 8, 2022 18:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

2 participants