Leave a running self-updating app alone during bootstrap packages upgrade

[azohra]

mise bootstrap packages upgrade replaced /Applications/Google Chrome.app under a running Chrome this evening, and every tab opened afterwards came up blank. I'd like to change the upgrade rule for auto_updates casks so a live app is skipped and left to its own updater. I have a PR ready and will link it below.

What happened

My machine config declares its apps through [bootstrap.packages], about twenty casks, and a machine update task runs mise bootstrap packages upgrade --yes over all of them. Fifteen of those casks declare auto_updates: true in their Homebrew metadata: Chrome, Slack, Zoom, VS Code, Obsidian, Discord, 1Password, Ghostty, OrbStack, and so on.

Chrome 153.0.8010.37 had just been published. The running Chrome was 152.0.7977.76 and Keystone hadn't applied the update yet. The upgrade rule for self-updating casks compares the live CFBundleShortVersionString with the cask version, saw 152 behind 153, and swapped the bundle:

/Applications/Google Chrome.app                                        18:45
/opt/homebrew/Caskroom/google-chrome/153.0.8010.37/.mise-cask.toml     18:46
Google Chrome Framework.framework/Versions/                            153.0.8010.37 only

The 152 browser process kept running, but it launches its renderer, GPU, and network helpers from its own versioned framework directory, which no longer existed. Every new tab rendered blank with an empty title. No crash report and nothing in the system log, just a browser that stopped working until relaunched. ps still listed the old 152 helpers at a path that no longer resolved.

Why the current rule is right, and still not enough

The live-version check is a good decision. It avoids Homebrew's --greedy habit of re-downloading apps that already updated themselves, and it only acts when the app is demonstrably behind. The gap is that "behind" and "safe to replace" are different questions. An app that is behind and running is almost always behind because its updater hasn't fired yet, not because it can't update. Replacing the bundle at that moment is the one case where mise does worse than doing nothing.

Chrome is the loudest failure, but any app that execs helpers from its bundle after launch has the same shape: Electron apps, Zoom, anything with a crashpad handler.

Proposal

In installed_skip_reason, for InstallMode::Upgrade on an auto_updates cask, after the live version has been judged outdated, check whether any process is running from inside the owned app bundle. If one is, skip with skipped: installed app is running and updates itself. Nothing else changes:

• non-self-updating casks keep today's behaviour, since skipping them would mean an always-open app never upgrades
• install and apply are untouched; they already leave installed self-updating apps alone
• dry-run reports the decision, and the recheck under the install lock applies it too, so an app launched during the download is still protected

Detection reads ps -axo comm= and matches by path component, the same shape as the pkgutil call in state.rs. Chrome's helpers show up under Contents/Frameworks/…/Helpers/…, so a component-wise starts_with on the bundle path catches the browser process and everything it spawned.

Things I considered and set aside:

• Skipping every auto_updates cask on upgrade, the way Homebrew's HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS opt-out does. That reverses a rule that already works and leaves a closed, outdated app behind; it might still earn a place as an explicit setting, but not as the default.
• Quitting the app first, the way Homebrew's quit: stanza does. Too surprising for an unattended --yes run.
• A per-package opt-out. Possibly useful later, but it treats the symptom; the default should be the safe one.

[azohra]

PR: #13041

[azohra]

Having sat with this, I want to put the smaller option on the table too. Homebrew ships HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS=1 for people who'd rather brew upgrade never touched a self-updating cask. A mise setting with the same meaning would solve my case outright: my update task runs bootstrap packages upgrade --yes unattended with everything open, which is exactly when the live-version rule bites. It's a few lines and leaves the default alone.

The running-app check in #13041 still looks like the better default to me. A swap under a live process breaks the app silently, and skipping a self-updating one costs nothing it won't recover on its own. But it's a heuristic over ps output and more code in a module you keep tight. If you'd rather have the opt-out, or both, say so and I'll pivot the PR.