mirror of
https://github.com/iv-org/invidious.git
synced 2025-08-21 18:59:02 -05:00
ded671ea6d
Of the technically four fibers spawned by `create_notification_stream` two of them are wrapped around an ensure clause to always unsubscribe itself from the notification job after an error, or when it simply finishes. The first is the heartbeat fiber, which is also actually the main fiber of the route handler. The second is a fiber that awaits for notification pushes from the notification job through the `connection` channel. When an error occurs within the main heartbeat fiber, the ensure clause is executed and the function will unsubscribe itself from receiving any pushes from the notification job. The problem however is that this could (will almost always actually) occur when the notification receiver fiber is awaiting a value from the notification job. Except the job will no longer be able to send anything to the receiver since they were unsubscribed by the heartbeat fiber just a moment ago. The notification receiver fiber will now block indefinitely. And in doing so will pretty much prevent the entire execution stack of the fiber and the `create_notification_stream` function from getting garbage collected. The IO buffers for the contents of the request and response will stay referenced, the underlying TCP/TLS sockets will become inaccessible and leaked, the parsed structures of the YT's massive JSON objects will stay allocated, etc. This PR simply merges the two into a single fiber, via a select statement ensuring that there will be no concurrency problems.