[wix-devs] WIXBUG5750 and RollbackBoundary

[Sean Hall]

I think it's easier right now to just say that the behavior is undefined
for whether a package will still be cached in those scenarios. Like Rob has
said, at some point we need to redo how Burn handles caching and this is
one thing that could be addressed.

On Tue, Jan 23, 2018 at 10:05 AM, Hoover, Jacob <Jacob.Hoover at greenheck.com>
wrote:

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