Repository navigation
fix(process): only match the current user's Spotify and daemon processes - #4010
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: spicetify/cli/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
On a machine where two accounts share one Spotify install,
apply,restoreand the other commands that stop Spotify also picked up the other account's Spotify, becausepgrepandpkillmatched every user's processes. The signal was refused, so each run waited out the 15-second shutdown timeout, then warned that the process "would not exit even when killed" and set it aside as stuck. The macOS daemon check had the same problem with another account'sspicetify-daemon.All
pgrepandpkillcalls on macOS and Linux now go through one helper that adds-U <uid>, using the current user's ID fromid -u. If that ID can't be read, they fall back to the previous behaviour. Windows is unchanged.Testing
On macOS, with a second account's Spotify running (PID 62208):
3.0.0-rc.2:applywaited 15 seconds, warnedSpotify process(es) [62208] would not exit even when killed, and took 26 seconds.applystopped only the current user's Spotify, printed no warnings, and took 15 seconds.cargo clippy --workspace -- -D warnings,cargo fmt --check, andcargo test -p spicetify(166 passed) are clean. The existing lifecycle tests still find and kill the current user's processes.