fix(instrumentation-http): set outgoing request attributes on start span

[blumamir]

Which problem is this PR solving?

Fixes #1255
Fixes #2320
And fix an HTTP instrumentation test: 'should have 1 ended span when request throw on bad "options" object'

For HTTP instrumentation, the span for outgoing request is currently started (startSpan) without any attributes. Only later when response arrives, request and response attributes are calculated and set on it. This is problematic in 2 situations:

• if exception is thrown before the response arrives (for example, if the parameters are not valid), then the span is closed and there are no attributes on it for user to understand the context (no URL, method).
• sampler can only take decisions based on attributes that are available during startSpan function call (on the options). Request attributes are already available at this point, but since they are not sent to startSpan, sampling is impossible for this case.

Additionally, there is a test for HTTP instrumentation called 'should have 1 ended span when request throw on bad "options" object', which calls http.request assuming it will throw, and then asserting in the catch block, but the function did not actually throw, so the test didn't check anything at all.

Short description of the changes

I moved the request attributes calculation to happen before starting the span (instead of doing it when response arrive), which solves the 2 issues above.
I also changed the mentioned test so it actually throws an error, and added assertions in it for the logic I changed in the code.

[blumamir]

Looks like I also pushed some layout changes in the http.ts which does not seem to be fixed by running lint:fix. I assume it happened when I clicked Options + Shift + F in vsc. Can someone point me to how I can revert them correctly?

[dyladan]

Looks like I also pushed some layout changes in the http.ts which does not seem to be fixed by running lint:fix. I assume it happened when I clicked Options + Shift + F in vsc. Can someone point me to how I can revert them correctly?

I see you pushed an update after this. Did you manage to get it fixed? In my experience when the lint:fix doesn't work it's because there is a syntax error preventing the linter from correctly parsing the file. Otherwise it will explicitly print what the error was that it couldn't fix.

[codecov]

Codecov Report

Merging #2349 (967a152) into main (5aabcc7) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #2349   +/-   ##
=======================================
  Coverage   92.77%   92.77%           
=======================================
  Files         145      145           
  Lines        5220     5221    +1     
  Branches     1069     1070    +1     
=======================================
+ Hits         4843     4844    +1     
  Misses        377      377           

Impacted Files	Coverage Δ
...ges/opentelemetry-instrumentation-http/src/http.ts	94.88% <100.00%> (-0.03%)	⬇️
...es/opentelemetry-instrumentation-http/src/utils.ts	99.02% <100.00%> (+<0.01%)	⬆️

[blumamir]

I see you pushed an update after this. Did you manage to get it fixed? In my experience when the lint:fix doesn't work it's because there is a syntax error preventing the linter from correctly parsing the file. Otherwise it will explicitly print what the error was that it couldn't fix.

Couldn't fix it yet. Looks like my IDE enforces a shorter line width (when calling "Option + Shift + F") which is something that is not configured in eslint.config.js for the project. Do you happen to know what is the value currently used in the project?

[blumamir]

Looks like I also pushed some layout changes in the http.ts which does not seem to be fixed by running lint:fix. I assume it happened when I clicked Options + Shift + F in vsc. Can someone point me to how I can revert them correctly?

reverted the changes manually (it wasn't fun). ready for review :)

[dyladan]

I see you pushed an update after this. Did you manage to get it fixed? In my experience when the lint:fix doesn't work it's because there is a syntax error preventing the linter from correctly parsing the file. Otherwise it will explicitly print what the error was that it couldn't fix.

Couldn't fix it yet. Looks like my IDE enforces a shorter line width (when calling "Option + Shift + F") which is something that is not configured in eslint.config.js for the project. Do you happen to know what is the value currently used in the project?

If it's not in the config it most likely uses the default value.

[blumamir]

If it's not in the config it most likely uses the default value.

I'm not very familiar with linting. Is the default value coming from the environment and can be potentially different in different setups?

[weyert]

I think we should define a prettier config file in the js-repos to avoid this mismatches

[weyert]

Looks good to me!