-
Notifications
You must be signed in to change notification settings - Fork 44
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
Conversation
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
// 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; |
There was a problem hiding this comment.
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
@kobik can you take a look at this? |
Hi @kdhira , thanks for the PR! I'll have a look tomorrow. |
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? |
There was a problem hiding this 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", |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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', () => { |
There was a problem hiding this comment.
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
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 |
There was a problem hiding this 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
d99901e
to
f1c554f
Compare
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 :) |
@kdhira, can you also revert the package-lock.json changes? I'd like to handle them in a separate PR. |
f1c554f
to
1ec335e
Compare
@kobik, I have dropped my commit that updated dependencies (and doing so reverted the package-lock.json changes I made). Hope this helps! |
Sure, thanks again @kdhira ! |
@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 |
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 |
Does the coveralls tool run the unit-tests or the integration tests (or both) to detect coverage? |
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 Should be ready to run the Github workflows again |
you're correct, for some reason it's only collected from integration tests. but also what you did should be fine 👍 |
🎉 This PR is included in version 3.2.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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