Closed HunterLarco closed 3 years ago
@zachguo @wiertz thoughts on this approach to handle stream disconnects?
In the case that an error occurs (eg: network weather) an error will be thrown from the async iterator. Meanwhile if a stream is disconnected healthily from Twitter's end it will simply end the stream. Practically this means if you want a 24/7 stream you would:
async function listenForever(streamFactory, dataConsumer) {
try {
for await (const { data } of streamFactory()) {
dataConsumer(data)
}
// The stream has been closed by Twitter. This may occur for many reasons and it is
// usually safe to reconnect.
listenForever(streamFactory, dataConsumer);
} catch (error) {
// An error occurred so we reconnect to the stream. Note that we should probably have
// retry logic here to prevent reconnection after a number of closely timed failures (may
// indicate a problem that is not downstream).
listenForever(streamFactory, dataConsumer);
}
}
listenForever(
() => client.stream('tweets/search/stream'),
(data) => console.log(data),
);
Looks good as far as I can tell and in contrast to my hack means that data is not croweded with signals and reconnect logic could be integrated into the package at some point. Do you know under what conditions a network disconnect will trigger the error event of the stream?
Looks good as far as I can tell and in contrast to my hack means that data is not crowded with signals and reconnect logic could be integrated into the package at some point. Do you know under what conditions a network disconnect will trigger the error event of the stream?
My understanding is that if the TCP body is malformed, an error will be thrown. If the stream is disconnected because of network inactivity, the timeout code should kick in and raise a "Stream unresponsive" error. And in the case of a healthy disconnect, no error will be thrown, but the stream will close.
In response to #53 and #48