[wix-devs] Burn bug: ARP entry

[Hoover, Jacob]

I can see migrating the cache changes to a final step in the plan for cache.  Still at a loss with you on the execute side.

My Default boundary issue has been resolved by just looking at pfKeepRegistration.

As for "if the current logic doesn't flag the failing packages cleanup logic":

When a package fails to execute, the existing rollback plan removes the cache for it. Since it may not be vital, we may continue to execute or we may rollback.  The comment was in regards to invoking the cache rollback plan, that it will again try to clean the failed packages cache, fail due to it not being there, and continue on with cleaning the rest.  The only down side is that it logs that it couldn't be removed. (Do we need a flag on the package indicating that the rollback has already happened, and as such we shouldn't call CleanCache on it again?

-----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:57 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] Burn bug: ARP entry

Sorry I took so long to respond. Your changes do look conceptually correct.

I'm still struggling to decide the best way to do this. On one hand, we're trying to do all the thinking while creating the plan so that ideally the two execute threads do very minimal work outside of the plan. This is adding work outside of the plan.

On the cache thread side, it wouldn't be hard to create a new kind of action (something like BURN_CACHE_ACTION_TYPE_WAIT_FOR_EXECUTE). This action would only be inserted in parallel mode, and would do what you added to CoreApply.

On the execute thread side, I still can't figure out a way to put this logic into the plan. In fact, I think there is more work that should be happening outside of the plan. For example, unless I'm mistaken, it looks like it's technically possible for the BA to cancel out of the Execute thread but let the Cache thread go to completion. I guess we could put something in the plan for that, but should the Cache thread really keep on downloading a (potentially 1+ GB) file when the Execute thread has already failed?


I don't understand your problem with WixDefaultBoundary at the beginning, it doesn't look like you changed anything around this? Is this related to your other email about RollbackBoundary expected behavior?

I also don't understand this statement from your bug either: "if the current logic doesn't flag the failing packages cleanup logic".

On Mon, Jan 22, 2018 at 1:04 PM, Hoover, Jacob via wix-devs < wix-devs at lists.wixtoolset.org> wrote:

> Pushed changes.
>
> New log: <snip>
>
> -----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 12:40 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> Subject: Re: [wix-devs] Burn bug: ARP entry
>
> Also FYI, the changes in my branch were conceptual, but in fact they 
> don't work as expected.
>
> I have a few local fixes which I can get it to work, but now my 
> problem is that the ApplyExecute plan always has a WixDefaultBoundary 
> at the beginning, which means my current condition is incorrect for 
> detecting if I hit a rollback boundary and I should not purge the cache.
>
> -----Original Message-----
> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> Behalf Of Hoover, Jacob via wix-devs
> Sent: Sunday, January 21, 2018 12:08 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Hoover, Jacob <Jacob.Hoover at greenheck.com>
> Subject: Re: [wix-devs] Burn bug: ARP entry
>
> FYI, https://github.com/wixtoolset/issues/issues/5750
>
> [https://avatars1.githubusercontent.com/u/2729285?s=400&v=4]<https://
> github.com/wixtoolset/issues/issues/5750>
>
> BURN: Error during ApplyExecute does not invoke cache rollback plan * 
> Issue #5750 * wixtoolset/issues * GitHub<https://github.com/ 
> wixtoolset/issues/issues/5750> github.com Tested in 3.7 (RTM), 3.11 
> (RTM), and develop. Using Visual Studio 2017 Ent. N/A on the IDE Ext 
> and .Net versions, this is native code.
> https://github.com/jchoover/wix-tests Build https://github.co...
>
>
> ________________________________
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> on behalf of 
> Hoover, Jacob via wix-devs <wix-devs at lists.wixtoolset.org>
> Sent: Friday, January 19, 2018 5:01:23 PM
> To: WiX Toolset Developer Mailing List
> Cc: Hoover, Jacob
> Subject: Re: [wix-devs] Burn bug: ARP entry
>
> So conceptually something like... 
> https://github.com/jchoover/wix3/commit/
> 74a76b0e2c0902e17d5ca7d42ca88cae64b510bf ?
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/