You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## 1. Socket Instrumentation Warnings from `aiohappyeyeballs`
4
+
5
+
### Background
6
+
7
+
aiohttp uses `aiohappyeyeballs` internally for connection management. This library implements the "Happy Eyeballs" algorithm (RFC 8305) for fast and reliable connection establishment by racing IPv4 and IPv6 connections.
8
+
9
+
When making HTTP requests, aiohttp's connection flow is:
10
+
11
+
1. Application calls `session.get()` or similar method
12
+
2. This calls `ClientSession._request()` (which we patch)
13
+
3. aiohttp internally uses `aiohappyeyeballs` to establish the TCP connection
14
+
4.`aiohappyeyeballs` uses low-level asyncio APIs like `loop.sock_connect()`
15
+
5. These schedule callbacks via the asyncio event loop
16
+
17
+
### Known Limitation
18
+
19
+
**Problem:** In REPLAY mode, socket instrumentation warnings are still logged for aiohttp requests, even though the HTTP layer is properly instrumented.
20
+
21
+
**Root Cause:** Python's `contextvars` propagate through `async/await` chains, but NOT through all asyncio internal callback mechanisms. When `aiohappyeyeballs` schedules socket operations via `loop.sock_connect()`, these run as event loop callbacks that don't inherit the `calling_library_context` we set in the patched `_request()` method.
22
+
23
+
The stack trace shows the context boundary:
24
+
25
+
```text
26
+
File "asyncio/events.py", line 88, in _run
27
+
self._context.run(self._callback, *self._args)
28
+
File "aiohappyeyeballs/_staggered.py", line 132, in run_one_coro
29
+
result = await coro_fn()
30
+
File "aiohappyeyeballs/impl.py", line 208, in _connect_sock
31
+
await loop.sock_connect(sock, address)
32
+
```
33
+
34
+
The `_context.run()` call creates a new context for the callback, which doesn't include our `calling_library_context`.
35
+
36
+
### Why This Happens Only with aiohttp
37
+
38
+
Other HTTP client libraries like httpx don't have this issue because:
|**CLI Alerts**| ⚠️ False positive alerts sent to CLI |
55
+
56
+
The warnings are cosmetic - they don't indicate actual unpatched dependencies since we successfully intercept at the higher `ClientSession._request()` level.
57
+
58
+
### Mitigation
59
+
60
+
The e2e test framework already handles this by skipping socket instrumentation warning checks for aiohttp:
61
+
62
+
```python
63
+
# Note: The socket instrumentation will detect and warn about these calls, but this
64
+
# is expected behavior. The warnings indicate that there are low-level socket calls
65
+
# happening that are not directly instrumented by our aiohttp instrumentation.
66
+
# This is normal for aiohappyeyeballs and doesn't indicate an instrumentation bug
67
+
# since we successfully intercept at the higher ClientSession._request() level.
68
+
```
69
+
70
+
### Code Location
71
+
72
+
The `calling_library_context` is set in `_patch_client_session()` in [`instrumentation.py`](./instrumentation.py):
**Potential approaches to eliminate the warnings:**
89
+
90
+
1.**Stack trace inspection**: Modify socket instrumentation to check the stack trace for known libraries like `aiohappyeyeballs` and suppress warnings. However, this adds overhead to every socket call and is fragile if library internals change.
91
+
92
+
2.**asyncio context propagation**: Python's `contextvars` module has `copy_context()` which could theoretically be used, but we don't control how `aiohappyeyeballs` or asyncio schedules callbacks.
93
+
94
+
3.**Library-specific skip list**: Add a configuration to socket instrumentation to skip warnings for known libraries. This is the most practical approach but requires maintenance as new libraries are added.
95
+
96
+
**Current approach:** Accept the warnings for aiohttp as expected behavior. The e2e test framework already handles this correctly, and the warnings don't affect functionality. Users who see these warnings in their logs can be informed they're expected for aiohttp.
97
+
98
+
### Test Coverage
99
+
100
+
The e2e tests verify that:
101
+
102
+
- All aiohttp request types work correctly in RECORD and REPLAY modes
103
+
- The socket instrumentation warning check is skipped for aiohttp
104
+
- Traces are captured correctly despite the warnings
0 commit comments