Open pmlanger opened 5 days ago
Happy to take care of that and submit a PR, should you agree about the problem and suggestion.
That would be great if you could. I'm happy to help shepherd the PR if needed. We shouldn't be crashing end user apps so I'd like to get this fixed ASAP.
@dyladan I gave it a shot: https://github.com/open-telemetry/opentelemetry-js/pull/5099
We have the same problem. I would like to solve it as soon as possible. How to help?
@LuiFerPereira https://github.com/open-telemetry/opentelemetry-js/pull/5099 has the fix; you can test it out if you like to. The PR is missing approval of workflow/reviews from maintainers and me addressing any comments (I am in CET timezone) :)
What happened?
Steps to Reproduce
I used the minimal/standard setup from the repository README to reproduce. Then, ran the server with
node -r ./tracing.js app.js
. Then, ran two requests against the server:Expected Result
For the server not to crash/still being able to handle the request; and the
open-telemetry-instrumentation-http
plugin to handle bad requests gracefully.Actual Result
Server/node process crashed with
uncaughtException
:Additional Details
The error thrown comes from forward-parse, in this line: https://github.com/lpinca/forwarded-parse/blob/master/index.js#L146 which is called by
open-telemetry-instrumentation-http
ingetIncomingRequestAttributes
(https://github.com/open-telemetry/opentelemetry-js/blob/eb3ca4fb07ee31c62093f5fcec56575573c902ce/experimental/packages/opentelemetry-instrumentation-http/src/utils.ts#L689) ->getServerAddress
-> usage offorwarded-parse
It feels like the
open-telemetry-instrumentation-http
should handle errors in the plugin itself, i.e., the error should not "leave" the plugin. It is quite expected that a client may send a malformed request, and the server should not crash on those. I could not find a really good way to prevent these errors. That is why I filed this as a bug report.But also happy to be educated whether there's a way to handle errors from plugins that I am not aware of.
Workaround
You might laugh at this, but for completeness: calling
getIncomingRequestAttributes
fromignoreIncomingRequestHook
like this is a hacky way to fix the issue for clients:Possible fix
A possible fix could be wrapping this part of the code https://github.com/open-telemetry/opentelemetry-js/blob/eb3ca4fb07ee31c62093f5fcec56575573c902ce/experimental/packages/opentelemetry-instrumentation-http/src/utils.ts#L575 (and the other occurrence in
getRemoteClientAddress
) into a try / catch and treating a parsing error gracefully in the same way as an absentForwarded
header. This seems to be in line with how the otherx-forwarded-*
headers are handled.Happy to take care of that and submit a PR, should you agree about the problem and suggestion.
OpenTelemetry Setup Code
package.json
Relevant log output