Hi, I believe handling of abort signal is broken in general.
First of all StatsigFetcher._retry doesn't receive or pass that in any way.
But even if it did it would have to create new signal each time, and since only signal is passed to the fetcher one cannot reliably know the timeout value with which it was constructed.
await Statsig.flush(100); // manually flush any unsent events
It takes timeout as parameter and an abort controller is created and signal is being passed further down. However if that request fails a retry request will be issued without any signal passed
Hi, I believe handling of abort signal is broken in general. First of all StatsigFetcher._retry doesn't receive or pass that in any way. But even if it did it would have to create new signal each time, and since only
signal
is passed to the fetcher one cannot reliably know the timeout value with which it was constructed.Consider the following scenario of invoking StatsigServer.flush function
It takes timeout as parameter and an abort controller is created and
signal
is being passed further down. However if that request fails a retry request will be issued without anysignal
passed