Unhandleable SIGPIPE when sending activity to closed client

[lilithium-hydride]

If I connect() to a running Discord client, close that client, and then send new data to it with set_activity(), the program crashes with Signal: SIGPIPE (Broken pipe). I'd expect that the error gets caught and returned in set_activity()'s result, but this does not happen.

Stack trace:

std::sys::unix::fd::FileDesc::write fd.rs:151
std::sys::unix::pipe::AnonPipe::write pipe.rs:62
std::process::{impl#6}::write process.rs:290
std::process::{impl#5}::write process.rs:271
std::io::Write::write_all<std::os::unix::net::stream::UnixStream> mod.rs:1532
discord_rich_presence::ipc_unix::{impl#1}::write ipc_unix.rs:80
discord_rich_presence::discord_ipc::DiscordIpc::send<discord_rich_presence::ipc_unix::DiscordIpcClient> discord_ipc.rs:114
discord_rich_presence::discord_ipc::DiscordIpc::set_activity<discord_rich_presence::ipc_unix::DiscordIpcClient> discord_ipc.rs:176
rich_presence_mpris::main::{closure#0} main.rs:123

rich_presence_mpris::main::{closure#0} main.rs:123:

match rpc_client.set_activity(payload) {
      Ok(_) => {}
      Err(err) => {
          eprintln!("Couldn't update Discord status. Is it running?")
      }
}

[lilithium-hydride]

Upon further investigation, it looks like there are quite a few places that crash instead of returning proper errors. Attempting to set_activity() while the connection is closed will unwrap a None value at discord_rich_presence::ipc_unix::{impl#1}::write ipc_unix.rs:78, and there does not appear to be a way to properly check the status of the connection beforehand given that DiscordIpcClient.connected isn't pub and there's no function that returns it (as far as I can tell).

[ghost]

thanks for bringing these issues up. I'm looking into it now and will get back to you when I have them addressed

[ghost]

hmm, I don't seem to be able to reproduce a stack trace like yours - my tests are having no problems catching the errors when I match against them. my test process is:

1. launch Discord
2. run tests/update_test.rs
3. quit discord before the second set_activity is to be called

it panics with the standard version of the test (since the ? assertion fails), but if i change it to a match identical to the snippet you shared, it prints the expected error text without issue

edit: I'm testing on arch linux with discord canary

[lilithium-hydride]

Well, I'm dumbfounded. I'm on Artix using discord-canary-electron-bin, so our setups aren't too dissimilar. I did the same thing as you and it worked, so I went back to my actual program to see what could be affecting it and it was no longer getting SIGPIPE'd. I tried to finish up the part of the code I was working on, and it began happening again. As I was trying to figure out what was causing it, it stopped. I'm now half-convinced I have vengeful spirits in my computer, but I think I can close this now. Thank you for the help!