[Gabriel Dufresne (GabrielDuf)]

Problem

When a process listed under Close apps before installing ignored the close request and "kill processes that refuse to close" was off, KillProcessOperation logged that the process would not be killed but still returned Success. The step was also queued with mustSucceed: false, so even a failure could not stop the update. The update then ran against the still-running app.

In #5076 this produced a phantom qBittorrent update. winget runs qBittorrent's NSIS installer silently. Its running-instance check is a wizard-page LEAVE callback, so it never runs under /S. NSIS then skips the locked qbittorrent.exe, because AllowSkipFiles makes the silent answer IDIGNORE. It still writes DisplayVersion 5.2.3 and exits 0. After that, neither winget nor UniGetUI can tell that the update didn't take. The installer behaviour is upstream. The only point where UniGetUI knows something is wrong is when a process it was asked to close is still running, and until now it carried on anyway.

Change

• KillProcessOperation returns Failure when a process survives the close step and force-kill is off.
• The user-configured close step is now required (mustSucceed: true), so its failure stops the operation. The operation fails with the existing "PreOperation … failed, and was tagged as necessary" line and offers the usual retry.

Deliberately unchanged:

• The automatic close-and-retry queued after winget reports the application is running stays optional. A failed close there only leads winget to fail again.
• Brokered operations, because the broker owns their kill step.

Behaviour change: if a user lists an app but leaves force-kill off, and the app ignores the close request (for example a tray app with no main window), the update now fails until they close the app. Before, it went ahead and could leave a half-updated install. An error raised while closing, such as access denied, now also stops the update.

Tests

• New KillProcessOperationTests start a windowless copy of cmd/sleep under a random name, so they can never touch a real app. They cover: a process that refuses to close fails the step, the same process with force-kill succeeds, and a name with no running process succeeds. The first test fails without the fix.
• The PackageOperationsTests check on the kill step now expects MustSucceed to be true.
• Full UniGetUI.PackageEngine.Tests passes on net10.0-windows (2863) and net10.0 (1968). Both dotnet format gates exit 0.

---

Closes #5076

[Copilot]

🟢 Approval recommended

No active review issues block the changes requiring configured app-closing steps to succeed before package operations continue.

No open issues 🎉

What changed in this PR

This PR prevents package operations from continuing when a user-configured “Close apps before installing” step fails, addressing the still-running-app scenario behind #5076.

Changes:

• Return failure when a process survives the close request and force-kill is disabled.
• Require user-configured close steps to succeed, while leaving automatic close-and-retry and brokered behavior unchanged.
• Add tests for refused closure, successful force-kill, and absent processes, and update prerequisite assertions.

File	Description
src/​UniGetUI.PackageEngine.Tests/​PackageOperationsTests.cs	Assert that configured close steps must succeed.
src/​UniGetUI.PackageEngine.Tests/​KillProcessOperationTests.cs	Add isolated process tests for close-step outcomes.
src/​UniGetUI.PackageEngine.Operations/​PackageOperations.cs	Make configured close steps required prerequisites.
src/​UniGetUI.PackageEngine.Operations/​KillProcessOperation.cs	Report failure when a process remains running without force-kill.

_{Review effort: Balanced}

[randy-but-a-ro]

🤖 Pull request was approved automatically: the AI review is complete and all its review threads are resolved. 🎉

Integration Details

{
	"deliveryId": "c3c25570-d30b-11f1-92d8-4955efde8513",
	"headSha": "a9864fc2c8476cd00ac49bab84bb052deac9c627",
	"reviewer": "copilot-pull-request-reviewer[bot]"
}