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.
textcaptcha.com seems to be down since April and it does not appear that
service will be restored.
Text captchas can be easily automated using free LLMs, so keeping the
text captcha is more like a gate to create accounts in mass on public
Invidious instances.
It also gives headaches like bots automating account creation to modify
the videos that appear popular page of each instance (since the popular
page is based on the subscriptions of the registered users).
Fixes https://github.com/iv-org/invidious/issues/5295
textcaptcha.com seems to be down since April and it does not appear that service will be restored.
Text captchas can be easily automated using free LLMs, so keeping the text captcha is more like a gate to create accounts in mass on public Invidious instances.
It also gives headaches like bots automating account creation to modify the videos that appear popular page of each instance (since the popular page is based on the subscriptions of the registered users).
Currently, Invidious uses QEMU to build it's ARM64 Invidious image,
which is slow (since we are basically using a virtual machine).
This helps with the speed of building ARM64 binaries for Invidious
on each release/commit.
More information about the public ARM64 runners here:
https://github.com/orgs/community/discussions/148648
CI: Use ARM64 compose file for build-docker-arm64
