[wix-devs] Rollback quirks

[Sean Hall]

My first attempt at replicating 3089 failed. I got TestBA to cancel the MSI
when the MSI progress event said 100% but that apparently wasn't late
enough. Does anyone know which BA event I can look for? Or does anyone know
what error code Burn is getting back from WiuInstallProduct? This is a lot
easier to handle if we're actually getting ERROR_SUCCESS since we can trust
the exit code.

On Wed, Jan 13, 2021 at 2:23 PM Sean Hall <r.sean.hall at gmail.com> wrote:

> > 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/
>>
>