Span doubling-tripling in aiohttp-client after multiple aiohttp.ClientSession Initialization

[i2xS]

Describe your environment
opentelemetry-instrumentation-aiohttp-client==0.33b0

Steps to reproduce

import asyncio

import aiohttp
from opentelemetry import trace
from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter
from opentelemetry.sdk.trace import TracerProvider, Resource
from opentelemetry.instrumentation.aiohttp_client import AioHttpClientInstrumentor

trace.set_tracer_provider(
    TracerProvider(resource=Resource.create({"service.name": "service1"}))
)
trace.get_tracer_provider().add_span_processor(BatchSpanProcessor(ConsoleSpanExporter()))
tracer = trace.get_tracer(__name__)
AioHttpClientInstrumentor().instrument()


async def check():
    aiohttp.ClientSession() # Just another initialisation, could be anywhere in the code

    with tracer.start_as_current_span("Parent"):
        async with aiohttp.ClientSession() as session:
            async with session.request(
                    'GET',
                    'https://google.com',
            ) as response:
                await response.read()


if __name__ == '__main__':
    loop = asyncio.get_event_loop()
    loop.run_until_complete(check())

What is the expected behavior?
Trace shoud contain only 2 spans - the one with name=Parent, and one child from actual request

What is the actual behavior?
Trace contains 3 spans. This number increases with more initializations of aiohttp.ClientSession() after AioHttpClientInstrumentor().instrument() is called

{
    "name": "HTTP GET",
    "context": {
        "trace_id": "0xf7d364422849e43fcd32a3b83186cd96",
        "span_id": "0x120dacfbe79e5846",
        "trace_state": "[]"
    },
    "kind": "SpanKind.CLIENT",
    "parent_id": "0x7b0a4189e34cf082",
    "start_time": "2022-09-01T06:30:49.199112Z",
    "end_time": "2022-09-01T06:30:49.891187Z",
    "status": {
        "status_code": "UNSET"
    },
    "attributes": {
        "http.method": "GET",
        "http.url": "https://google.com",
        "http.status_code": 200
    },
    "events": [],
    "links": [],
    "resource": {
        "attributes": {
            "telemetry.sdk.language": "python",
            "telemetry.sdk.name": "opentelemetry",
            "telemetry.sdk.version": "1.12.0",
            "service.name": "service1"
        },
        "schema_url": ""
    }
}
{
    "name": "HTTP GET",
    "context": {
        "trace_id": "0xf7d364422849e43fcd32a3b83186cd96",
        "span_id": "0x9b00527d2a7a7a7d",
        "trace_state": "[]"
    },
    "kind": "SpanKind.CLIENT",
    "parent_id": "0x120dacfbe79e5846",
    "start_time": "2022-09-01T06:30:49.199211Z",
    "end_time": "2022-09-01T06:30:49.891231Z",
    "status": {
        "status_code": "UNSET"
    },
    "attributes": {
        "http.method": "GET",
        "http.url": "https://google.com",
        "http.status_code": 200
    },
    "events": [],
    "links": [],
    "resource": {
        "attributes": {
            "telemetry.sdk.language": "python",
            "telemetry.sdk.name": "opentelemetry",
            "telemetry.sdk.version": "1.12.0",
            "service.name": "service1"
        },
        "schema_url": ""
    }
}
{
    "name": "Check client spans",
    "context": {
        "trace_id": "0xf7d364422849e43fcd32a3b83186cd96",
        "span_id": "0x7b0a4189e34cf082",
        "trace_state": "[]"
    },
    "kind": "SpanKind.INTERNAL",
    "parent_id": null,
    "start_time": "2022-09-01T06:30:49.198845Z",
    "end_time": "2022-09-01T06:30:49.897274Z",
    "status": {
        "status_code": "UNSET"
    },
    "attributes": {},
    "events": [],
    "links": [],
    "resource": {
        "attributes": {
            "telemetry.sdk.language": "python",
            "telemetry.sdk.name": "opentelemetry",
            "telemetry.sdk.version": "1.12.0",
            "service.name": "service1"
        },
        "schema_url": ""
    }
}

Additional context
On opentelemetry-instrumentation-aiohttp-client==0.29b0 the issue is not reproduced.

[srikanthccv]

I believe this was fixed in #1246

[i2xS]

yeah, thanks. Did'n find that.