[wix-devs] WIXBUG5750 and RollbackBoundary

[Hoover, Jacob]

I'm liking the simplification of if it's in ARP, then the cache can stay, however the current plan executes a rollback of a cached package if it fails. Are you saying this behavior should change, or just the concept of cleaning the cache should only happen if ARP = False?

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Sean Hall via wix-devs
Sent: Monday, January 22, 2018 11:52 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: Re: [wix-devs] WIXBUG5750 and RollbackBoundary

I agree, if the bundle is going to stay registered in ARP then it should be allowed to keep packages in the cache. And it sounds like a good idea to try not to clean the cache to save time for a later attempt.

I haven't looked at the code, but I would expect the Chain/@DisableRollback to essentially insert a RollbackBoundary between every package.

(I numbered your examples below)

(1) A stays installed, so bundle stays registered in ARP, so cache can stay.
(2) same as 1.
(3) A is rolled back, nothing is installed so bundle unregisters from ARP, all packages and bundle are cleared from cache.
(4) RollbackBoundary causes the rollback to stop there. A stays installed, so bundle stays registered in ARP, so cache can stay.
(5) same as 4.
(6) same as 1.

On Mon, Jan 22, 2018 at 5:17 PM, Bob Arnson via wix-devs < wix-devs at lists.wixtoolset.org> wrote:

> My vote: Cache should be tied to registration, so "registered in ARP 
> == cached as originally requested." Just because a package failed to 
> install shouldn't eject it from the cache, if the bundle is still 
> registered (so the user can try again without another download).
>
> As I recall (and I don't entirely trust my recollection as I wasn't 
> physically present or deeply involved at the time), package vitality 
> and rollback boundaries were to prevent a transient or simple failure 
> from triggering a painful (in time consumed) rollback and reinstall. 
> IOW, keep as much on the machine as possible so the user could retry.
>
> -----Original Message-----
> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> Behalf Of Hoover, Jacob via wix-devs
> Sent: Monday, 22 January, 2018 17:34
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> Subject: Re: [wix-devs] WIXBUG5750 and RollbackBoundary
>
> Also, what would the expected state of the cache be under this condition:
>
> (6)<Chain DisableRollback="Yes">
>   <MsiPackage SourceFile="A.msi" />
>   <MsiPackage SourceFile="Fail.msi" />
>   <MsiPackage SourceFile="B.msi" />
> </Chain>
>
> Should B still be cached?
>
> -----Original Message-----
> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> Behalf Of Hoover, Jacob via wix-devs
> Sent: Monday, January 22, 2018 4:06 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> Subject: [wix-devs] WIXBUG5750 and RollbackBoundary
>
> With regards to a rollback boundary, what is the expected behavior of 
> Burn when a package is authored with or without explicit rollback 
> boundaries, and an error happens during apply execute?
>
> Chain/@DisableRollback - The default is "no" which indicates all 
> packages executed during the chain will be rolledback to their 
> previous state when a vital package fails. If "yes" is specified then 
> when a vital package fails to install only that package will rollback 
> and the chain will stop with the error.
>
> RollbackBoundary/@Vital - Specifies whether the rollback boundary 
> aborts the chain. The default "yes" indicates that if the rollback 
> boundary is encountered then the chain will fail and rollback or stop.
>
> (1)<Chain DisableRollback="Yes">
>   <MsiPackage SourceFile="A.msi" />
>   <RollbackBoundary Vital="No"/>
>   <MsiPackage SourceFile="Fail.msi" /> </Chain> In this example, my 
> impression is that because the failure happened on a vital package in 
> a non-vital rollback boundary, that the bundle would be considered 
> installed and that Fail MSI would have its package cache cleared.
>
> (2)<Chain DisableRollback="Yes">
>   <MsiPackage SourceFile="A.msi" />
>  <MsiPackage SourceFile="Fail.msi" />
> </Chain>
> In this example, I am expecting the A MSI to remain, and the Fail MSI 
> to just have its cache cleared.
>
> (3)<Chain>
>   <MsiPackage SourceFile="A.msi" />
>  <MsiPackage SourceFile="Fail.msi" />
> </Chain>
>                 In this example, I would expect both MSI's to be 
> removed, and their caches purged.
>
> (4)<Chain>
>   <MsiPackage SourceFile="A.msi" />
>   <RollbackBoundary/>
>   <MsiPackage SourceFile="Fail.msi" /> </Chain>
>                 In this example, is this RollbackBoundary ignored 
> because it has the same attributes as the default boundary? Meaning if 
> this chain was installing, a failure would cause A to be uninstalled, 
> and both to have their caches cleared?
>
> (5)<Chain>
>   <RollbackBoundary Vital="No"/>
>   <MsiPackage SourceFile="A.msi" />
>   <MsiPackage SourceFile="Fail.msi" Vital="No" />
>   <RollbackBoundary Vital="Yes">
>   <MsiPackage SourceFile="SecondFail.msi" /> </Chain>
>                 In this example, A would get installed, Failed would 
> be attempted, but then ignored due to the Packages Vital state (but 
> the cache should be cleared), Followed by the SecondFail triggering a 
> rollback of everything?
>
> Thanks,
> Jacob
>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/ ______________________________ 
> ______________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/ 
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/