[decbr]

Flatpak is one of the many, many confusing ways that Linux packages software

if you ran a third party client as a Flatpak (notably Vesktop, but other options are available (Legcord or Equibop)), Perigee couldn't find them. they put their IPC socket in $XDG_RUNTIME_DIR/.flatpak/<app-id>/xdg-run/discord-ipc-0 and that never got checked.

This PR adds a check to flatpak sockets.

Changes

1. Scan every .flatpak/*/xdg-run/

EndpointResolver now lists $XDG_RUNTIME_DIR/.flatpak/ and adds any app folder that has an xdg-run inside it. Any Flatpak client (current or future!) gets found. No .flatpak/ or can't read it returns empty list, same behaviour as before. Any other folder such as per-instance folders like 1234567890 and 1234567890-private have no xdg-run, so they're skipped.

This does pick up flatpaks that aren't discord at all, though, should they have an xgd-run folder. on my machine it found surfshark, for example, but since surfshark has no discord-ipc-n it fails on no such file.

resolve() now reads disk, therefore, where it used to just glue strings together from env and its arguments. now it calls flatpakRuntimeDirs inside the XDG_RUNTIME_DIR branch, which runs Files.list on .flatpak/ and Files.isDirectory on each xdg-run. Benefit of this is to not have to add a line every time a new client turns up on Flathub.

2. Log which endpoint failed

While checking the above I found that a failed connect is kinda useless to debug. The JDK's Unix socket errors don't include the path so the suppressed exceptions were about 100 copies of No such file or directory and nothing else. each one now reads like this:

/run/user/1000/.flatpak/com.surfshark.Surfshark/xdg-run/discord-ipc-0: java.net.SocketException: No such file or directory

3. Test Changes

1. New test: a temp runtime dir with dev.vencord.Vesktop/xdg-run/ and an instance folder. Vesktop is found after the sandboxes, and the instance folder isn't.

2. unixFollowsDocumentedOrderWithSandboxesAndFallback now uses /run/user/1 instead of /run/user/1000.
   resolve() reads the disk, and /run/user/1000 is a real folder on most Linux desktops (including mine, hence Surfshark turning up in the expected list). uid 1 (or any number under 1000 except 0) never logs in so the folder never exists.

3. reportsHowDiscordTreatsEachActivityType used to time out on its last clear. That was the test's fault: it sends 6 updates inside Discord's 5-per-20-seconds presence limit and only waited 10 seconds for the 6th, which the rate limiter was holding back exactly like it should. It now waits 30.

---

tested on arch. tested with extra/discord, aur/vesktop, and flatpak discord (Flathub com.discordapp.Discord)

Client	Path	Found by	Close
Flatpak Discord	.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-0	the new scan	25 ms
Flatpak Discord	app/com.discordapp.Discord/discord-ipc-0	SANDBOX_SUBDIRS	20 ms
aur/vesktop	discord-ipc-0	plain $XDG_RUNTIME_DIR	44 ms
extra/discord	discord-ipc-1	plain $XDG_RUNTIME_DIR	9 ms

the first one is the real socket, the second only exists because the Flathub package runs socat to forward app/... to it, which is the whole reason the hard-coded path ever worked. Vesktop and others don't ship that forwarder so xdg-run is all they've got.

thank you for reading! i actually genuinely wrote all of this