[wix-devs] Burn bug: ARP entry

[Sean Hall]

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