[wix-devs] Rollback quirks

[Sean Hall]

> If it is helpful, I agree in 5950 it would be ideal if all packages
rolled back the way MSI packages do now--if the package can be uninstalled

I do think the fix for 5950 is to make it consistent for all packages. Are
you aware that it's done this way for all operations, not just
execute=install and rollback=uninstall?

> It is probably a bit more complicated with ExePackages since they would
need to re-detect

If we do make the behavior consistent, I'm starting to wonder if we should
do that for all package types to see whether or not to actually do the
planned rollback action. In which case, why not just re-detect as the way
to track whether it's installed?

>> But what happens if the rollback also fails?

You skipped the question in step 3, but your response makes it sound like
you think the tracking should assume that the execute action was successful
even if the exit code indicated failure. If we're making that assumption
during execute, then yes we should make the same assumption during rollback.

> I'd have to defer to the current behavior of Burn with
DisableRollback="yes". Does failure during install of a latter package in
the chain with disabled rollback keep the Bundle registration or remove it?

The current ARP behavior is useless to me. But if you want to know, in v3
with the following scenario the registration is kept:

0. Bundle was not already installed, executing Install action.
1. non-permanent MsiPackageB is executed for install.
2. MsiPackageB returns success.
3. vital MsiPackageC is executed for install.
4. MsiPackageC returns failure.
5. Rollback is disabled so execution ends immediately.

That's not the scenario I was interested in, though. I was wondering about
what happens if MsiPackageB failed.

> Aside: IIRC, Burn in rollback mode ignores cancel requests

Maybe my reason for rollback failing is a bad example. Just imagine
something else causing the same outcome, which could be much easier with
ExePackages and brittle DetectConditions. (Also, v4 allows showing UI for
MSI during uninstall).


On Wed, Jan 13, 2021 at 1:38 PM Rob Mensching <rob at firegiant.com> wrote:

> > None of the other package types were updated with this logic, causing
> issues like https://github.com/wixtoolset/issues/issues/5950
>
> If it is helpful, I agree in 5950 it would be ideal if all packages rolled
> back the way MSI packages do now--if the package can be uninstalled (i.e.
> well-known uninstall or has UninstallArguments, etc.). It is probably a bit
> more complicated with ExePackages since they would need to re-detect to see
> if they were successfully installed before trying to launch their uninstall
> command. An ExePackage's uninstall behavior is too undefined to simply
> launch uninstall without knowing that the exe was installed.
>
> > But what happens if the rollback also fails?
>
> If rollback--or the uninstall command to replicate rollback if the package
> was installed--fails, I think we'll just have to move on with life
> pretending it worked. In other words, ignore rollback results. There are
> trade-offs here but my initial instincts tell me that removal even with
> rollback failure is the lesser of evils. A solid counter argument could
> absolutely sway me.
>
> > Or maybe for DisableRollback="yes", we should never uninstall the bundle?
>
> I'd have to defer to the current behavior of Burn with
> DisableRollback="yes". Does failure during install of a latter package in
> the chain with disabled rollback keep the Bundle registration or remove it?
>
>
> Aside: IIRC, Burn in rollback mode ignores cancel requests. I'm pretty
> sure this is the same behavior as MSI. The user can't cancel rollback.
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Tuesday, January 12, 2021 4:42 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: [wix-devs] Rollback quirks
>
> I'm trying to implement 6297, but I'm getting hung up on how we're doing
> rollback for execute package actions. Remember that I'm trying to track
> what the actual state of the package is during execution, to get an
> accurate count of the number of non-permanent packages that are installed.
>
> From https://github.com/wixtoolset/issues/issues/3089, MSI packages are
> planned such that if there is a rollback execute action then that will be
> executed during rollback even if the package had failed. (None of the other
> package types were updated with this logic, causing issues like
> https://github.com/wixtoolset/issues/issues/5950).
>
> So how do I handle failure of the non-rollback execute action? Should I be
> conservative like 3089 which would mean for example that even if the
> install failed, I treat it as installed? At first you might think that it
> doesn't matter, because rollback should undo it. But what happens if the
> rollback also fails? Also, if the bundle has DisableRollback="yes" then it
> would never try to rollback the package, and that could mean the difference
> between keeping the bundle registered or not. Or maybe for
> DisableRollback="yes", we should never uninstall the bundle?
>
> DisableRollback="no" scenario:
> 0. Bundle was not initially installed, and had no packages installed or
> cached.
> 1. MsiPackageA is executed for install.
> 2. MsiPackageA returns error, but it actually installed successfully.
> The user had canceled too late.
> 3. (Track this as installed or not?)
> 4. Rollback executes MsiPackageA for uninstall.
> 5. MsiPackagesA returns error, but it actually uninstalled successfully.
> The user had canceled too late.
> 6. (If we tracked as installed in #3, then do we now treat it as
> uninstalled?)
> 7. MsiPackageA gets uncached.
> 8. We're supposed to uninstall the bundle here if MsiPackageA is not
> installed.
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>