fix(ws): avoid retaining connection span#7469
Conversation
Run ws socket setup in a store scope without the connection span so internal ws handlers don't capture and keep it alive.
Overall package sizeSelf size: 4.58 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 2.0.6 | 81.92 kB | 813.08 kB | | dc-polyfill | 0.1.10 | 26.73 kB | 26.73 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #7469 +/- ##
==========================================
- Coverage 80.34% 80.31% -0.03%
==========================================
Files 731 731
Lines 31093 31140 +47
==========================================
+ Hits 24981 25011 +30
- Misses 6112 6129 +17
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
BenchmarksBenchmark execution time: 2026-02-11 15:07:29 Comparing candidate commit 7b2932d in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 231 metrics, 29 unstable metrics. |
This comment has been minimized.
This comment has been minimized.
rochdev
left a comment
There was a problem hiding this comment.
A few non-blocking nitpicks, but otherwise LGTM!
|
|
||
| // Bind the setSocket channel so internal ws event handlers (data, close) | ||
| // don't capture their async context. | ||
| this.addBind('tracing:ws:server:connect:setSocket', () => {}) |
There was a problem hiding this comment.
Nit, but I think this would be a case where explicitly returning undefined makes the intent clearer.
There was a problem hiding this comment.
Our linter prohibits that. I would have to add an exception for that which is also meh
| agent.close({ ritmReset: false, wipe: true }) | ||
| }) | ||
|
|
||
| it('should not retain the connection span during socket setup', async () => { |
There was a problem hiding this comment.
Nit: I'd probably reword this, as that's actually only a side effect. If a span shouldn't be active, it means that those handlers were previously in the wrong context, so that's the real problem that the test is testing for.
Run ws socket setup in a store scope without the connection span so internal ws handlers don't capture and keep it alive.
Run ws socket setup in a store scope without the connection span so internal ws handlers don't capture and keep it alive.
Run ws socket setup in a store scope without the connection span so internal ws handlers don't capture and keep it alive.
Run ws socket setup in a store scope without the connection span so internal ws handlers don't capture and keep it alive.