fix: use socket from the request

[mzahor]

Fixes #1377

@blumamir and I investigated this issue and were able to reproduce it.
It happens if client uses the same TCP connection to send multiple requests (in keep-alive mode for example), so that there are multiple active requests on the same socket.
In this scenario, there is one socket for two request/response pairs and this socket is attached only to a single response on every given time.
So it may happen, that the instance of OutgoingMessage (response in our case), will not have a socket attached when handler calls the response.end function. In this case, the data will be pushed into an internal buffer https://github.com/nodejs/node/blob/75fd447/lib/_http_outgoing.js#L334.
But in http plugin we try to access some properties of the socket, since it's equal to null we get an unhandledException event and server crashes.
Since the socket instance is the same for both request and response, it's enough to use request.socket to fix this issue and still have the same instrumentation data.

This is a small tool that we used to simulate this scenario:

package main

import (
	"bufio"
	"fmt"
	"io"
	"net"
)

func main() {
	message := "GET / HTTP/1.1\n\n"

	c, err := net.Dial("tcp", "localhost:8088")
	check(err)

	fmt.Printf(">> sending first message \n")
	_, err = fmt.Fprintf(c, "%s", message)
	check(err)

        // don't read the response and send another message
	fmt.Printf(">> sending second message \n")
	_, err = fmt.Fprintf(c, "%s", message)
        // otel should error at this point
	check(err)

	fmt.Printf("== reading responses \n")
	for {
		response, err := bufio.NewReader(c).ReadString('\n')
		if err == io.EOF {
			continue
		}
		check(err)
		fmt.Printf("<< %s\n", response)
	}
}

func check(e error) {
	if e != nil {
		panic(e)
	}
}

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Marian Zagoruiko (b654fa4)

[codecov]

Codecov Report

Merging #1939 (48cd0db) into main (9437d7e) will increase coverage by 1.73%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1939      +/-   ##
==========================================
+ Coverage   92.62%   94.35%   +1.73%     
==========================================
  Files         170       26     -144     
  Lines        5733     2020    -3713     
  Branches     1192      477     -715     
==========================================
- Hits         5310     1906    -3404     
+ Misses        423      114     -309     

Impacted Files	Coverage Δ
...es/opentelemetry-instrumentation-http/src/utils.ts	99.03% <100.00%> (+0.48%)	⬆️
packages/opentelemetry-plugin-http/src/utils.ts	99.03% <100.00%> (+0.49%)	⬆️
...ges/opentelemetry-instrumentation-http/src/http.ts	94.69% <0.00%> (-0.82%)	⬇️
...s/opentelemetry-metrics/src/UpDownCounterMetric.ts
.../opentelemetry-api/src/platform/node/globalThis.ts
...entelemetry-metrics/src/UpDownSumObserverMetric.ts
...telemetry-tracing/src/export/BatchSpanProcessor.ts
...src/platform/node/instrumentationNodeModuleFile.ts
...sync-hooks/src/AbstractAsyncHooksContextManager.ts
packages/opentelemetry-api/src/api/context.ts
... and 139 more

[mzahor]

I tested it manually and everything worked. I'll check what's wrong w/ the unit tests tomorrow.

[dyladan]

Awesome thanks for the contribution. Looks like a simple enough change and my guess is the test failures are because the mocks assumed the response is used but I'll hold off until tests are fixed.

[mzahor]

@dyladan I've fixed the tests, also added an integration test for this case. Please take another look.

[obecny]

lgtm

[vmarchaud]

@mzahor FYI the PR need be rebased and its seems we can't do it ourselves from the github UI

[mzahor]

@vmarchaud Rebased.