@@ -33,28 +33,6 @@ export class NodeClient extends ServerRuntimeClient<NodeClientOptions> {
33
33
) ;
34
34
35
35
super ( clientOptions ) ;
36
-
37
- if ( clientOptions . sendClientReports !== false ) {
38
- // There is one mild concern here, being that if users periodically and unboundedly create new clients, we will
39
- // create more and more intervals and beforeExit listeners, which may leak memory. In these situations, users are
40
- // required to call `client.close()` in order to dispose of the acquired resources.
41
- // Users are already confronted with the same reality with the SessionFlusher at the time of writing this so the
42
- // working theory is that this should be fine.
43
- // Note: We have experimented with using `FinalizationRegisty` to clear the interval when the client is garbage
44
- // collected, but it did not work, because the cleanup function never got called.
45
- this . _clientReportInterval = setInterval ( ( ) => {
46
- DEBUG_BUILD && logger . log ( 'Flushing client reports based on interval.' ) ;
47
- this . _flushOutcomes ( ) ;
48
- } , CLIENT_REPORT_FLUSH_INTERVAL_MS )
49
- // Unref is critical, otherwise we stop the process from exiting by itself
50
- . unref ( ) ;
51
-
52
- this . _clientReportOnExitFlushListener = ( ) => {
53
- this . _flushOutcomes ( ) ;
54
- } ;
55
-
56
- process . on ( 'beforeExit' , this . _clientReportOnExitFlushListener ) ;
57
- }
58
36
}
59
37
60
38
/** Get the OTEL tracer. */
@@ -99,4 +77,36 @@ export class NodeClient extends ServerRuntimeClient<NodeClientOptions> {
99
77
100
78
return super . close ( timeout ) ;
101
79
}
80
+
81
+ /**
82
+ * Will start tracking client reports for this client.
83
+ *
84
+ * NOTICE: This method will create an interval that is periodically called and attach a `process.on('beforeExit')`
85
+ * hook. To clean up these resources, call `.close()` when you no longer intend to use the client. Not doing so will
86
+ * result in a memory leak.
87
+ */
88
+ // The reason client reports need to be manually activated with this method instead of just enabling them in a
89
+ // constructor, is that if users periodically and unboundedly create new clients, we will create more and more
90
+ // intervals and beforeExit listeners, thus leaking memory. In these situations, users are required to call
91
+ // `client.close()` in order to dispose of the acquired resources.
92
+ // We assume that calling this method in Sentry.init() is a sensible default, because calling Sentry.init() over and
93
+ // over again would also result in memory leaks.
94
+ // Note: We have experimented with using `FinalizationRegisty` to clear the interval when the client is garbage
95
+ // collected, but it did not work, because the cleanup function never got called.
96
+ public startClientReportTracking ( ) : void {
97
+ if ( this . getOptions ( ) . sendClientReports !== false ) {
98
+ this . _clientReportOnExitFlushListener = ( ) => {
99
+ this . _flushOutcomes ( ) ;
100
+ } ;
101
+
102
+ this . _clientReportInterval = setInterval ( ( ) => {
103
+ DEBUG_BUILD && logger . log ( 'Flushing client reports based on interval.' ) ;
104
+ this . _flushOutcomes ( ) ;
105
+ } , CLIENT_REPORT_FLUSH_INTERVAL_MS )
106
+ // Unref is critical for not preventing the process from exiting because the interval is active.
107
+ . unref ( ) ;
108
+
109
+ process . on ( 'beforeExit' , this . _clientReportOnExitFlushListener ) ;
110
+ }
111
+ }
102
112
}
0 commit comments