You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we're using Tokio's channels for the .await support in AsyncLogger::run. This means we need to use Sender::try_send since Tokio's Sender::send is async, and io::Write needs to be synchronous.
However, this also means if the buffer is full, we can't write that data out, and we don't block on it. Instead, we return a io::ErrorKind::OutOfMemory.
Unfortunately, asciinema doesn't seem to do anything with this (like apply backpressure to the stream), so we silently drop logs instead. This is unfortunate, particularly if you're using the logging functionality for security-oriented purposes (like an audit log).
This might be fixable by switching to std::sync::mpsc::sync_channel instead, whose Sender::send is blocking (or std::sync::mpsc::channel which has an "infinite buffer", no idea how that works) - however, this means the Receiver side can't use timeout().await and needs to use recv_timeout instead.
Not sure on the implications or if this will even work - or if blocking is even desirable! tbd.
The text was updated successfully, but these errors were encountered:
Currently, we're using Tokio's channels for the
.await
support inAsyncLogger::run
. This means we need to useSender::try_send
since Tokio'sSender::send
is async, andio::Write
needs to be synchronous.However, this also means if the buffer is full, we can't write that data out, and we don't block on it. Instead, we return a
io::ErrorKind::OutOfMemory
.Unfortunately, asciinema doesn't seem to do anything with this (like apply backpressure to the stream), so we silently drop logs instead. This is unfortunate, particularly if you're using the logging functionality for security-oriented purposes (like an audit log).
This might be fixable by switching to
std::sync::mpsc::sync_channel
instead, whoseSender::send
is blocking (orstd::sync::mpsc::channel
which has an "infinite buffer", no idea how that works) - however, this means the Receiver side can't usetimeout().await
and needs to userecv_timeout
instead.Not sure on the implications or if this will even work - or if blocking is even desirable! tbd.
The text was updated successfully, but these errors were encountered: