-
Notifications
You must be signed in to change notification settings - Fork 552
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
fix(instrumentation-fastify): fix span attributes and avoid FSTDEP017 FastifyDeprecation warning for 404 request #1763
Conversation
…ion warning for 404 request For a 404 `request.routeOptions.url` is undefined. Since fastify@4.10.0 when routeOptions was added, we shouldn't fallback to the deprecated request.routerPath. This also corrects the assumption that the handler name is "bound ..." in all cases. E.g. for a 404 it is Fastify's core "basic404" internal function. Fixes: open-telemetry#1757
@pichlermarc I have a side question about the .tav.yml file for instrumentation-fastify (added in #1710). Is it the intention to only test with a single explicit version of fastify ("4.23.2")? Oh, or do I need to not update the fastify version in "package.json" in this PR, because versions after 4.18.0 require a typescript greater than 4.4.4? I'll see if CI fails and then move it back to If we want --- a/plugins/node/opentelemetry-instrumentation-fastify/.tav.yml
+++ b/plugins/node/opentelemetry-instrumentation-fastify/.tav.yml
@@ -1,5 +1,5 @@
-"fastify":
- - versions: "4.23.2"
+fastify:
+ - versions: "4.0.0 || >4.24.3 <5"
commands: npm run test
"typescript":
- versions: "4.7.4" This would sanity test with the first 4.0.0 release and then with any releases at or after the current latest. This does require occasionally bump that |
…er typescript than 4.4.4
Indeed it did fail the |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #1763 +/- ##
==========================================
- Coverage 91.50% 91.48% -0.03%
==========================================
Files 144 144
Lines 7369 7374 +5
Branches 1467 1471 +4
==========================================
+ Hits 6743 6746 +3
- Misses 626 628 +2
|
anyRequest.routeOptions?.config?.url || request.routerPath; | ||
const routeName = anyRequest.routeOptions | ||
? anyRequest.routeOptions.url | ||
: request.routerPath; |
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.
Regarding the codecov warning on this line and below: TAV tests could cover line 101, but currently they won't because it doesn't go back to an early-enough fastify version. Shall I add an // istanbul ignore next
directive here?
Update: Actually, perhaps an istanbul
directive won't help, because that is what nyc
is using. I don't know what codecov is using. When I run the tests locally, I get different lines that are uncovered:
---------------------|---------|----------|---------|---------|-------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
---------------------|---------|----------|---------|---------|-------------------
All files | 93.91 | 75.24 | 94.73 | 93.91 |
src | 93.43 | 73.68 | 94.28 | 93.43 |
constants.ts | 100 | 100 | 100 | 100 |
instrumentation.ts | 96.07 | 80 | 100 | 96.07 | 153-157,161,235
utils.ts | 84.84 | 56 | 71.42 | 84.84 | 107-113,119
src/enums | 100 | 100 | 100 | 100 |
AttributeNames.ts | 100 | 100 | 100 | 100 |
---------------------|---------|----------|---------|---------|-------------------
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.
Interesting; AFAIK codecov uses the reports generated by istanbul, so adding the directive should help. Looks like the uncovered lines above are actually not tested at the moment (see full file on the codecov report - not sure if you have access). We could also add an earlier fastify version to TAV if that fixes the issue.
I've just recently added TAV to this package, having more versions tested would likely be a good idea anyway.
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've added testing of fastify@4.0.0 plus the current latest and any subsequent fastify 4.x releases to the .tav.yml.
I don't know if coverage data from TAV runs get included in the codecov summary.
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 right, it looks like reports from TAV are not included.
IMO just having the version tested is good enough for now, we may look into adding coverage from TAV in the future, but we've been having problems with codecov for a while now, so I think this will likely be a larger task.
Sorry, I was out of office so I wasn't able to respond. This is exactly the reason. We can't bump beyond 4.4.4 because the fastify instrumentation is included by |
@pichlermarc The
I was inclined to wait for #1771 to go in first to get some improvements to the npm install handling. When that is merged, I'll update this PR and dig into the test failure if it still exists. |
Ready for review, modulo the package-lock.json update discussion in #1806 |
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.
Looks good, thanks for fixing this 👍
anyRequest.routeOptions?.config?.url || request.routerPath; | ||
const routeName = anyRequest.routeOptions | ||
? anyRequest.routeOptions.url | ||
: request.routerPath; |
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 right, it looks like reports from TAV are not included.
IMO just having the version tested is good enough for now, we may look into adding coverage from TAV in the future, but we've been having problems with codecov for a while now, so I think this will likely be a larger task.
For a 404,
request.routeOptions.url
is undefined. Since fastify@4.10.0when routeOptions was added, we shouldn't fallback to the deprecated
request.routerPath.
This also corrects the assumption that the handler name is "bound ..."
in all cases. E.g. for a 404 it is Fastify's core "basic404" internal
function.
Fixes: #1757