‘If previous action fails’ not catching

[spruitt]

Absolutely love this software. The new ‘goto label’ is great.

I have a job queue that downloads and installs updates in a loop until there are none left. Since I used cached mode, sometimes 1 update will fail to download or copy over due to “invalid characters in path” or some some exception error. I read the blog and found that disabling cached mode fixes this. Easy. However, my Job queue is set to disable cached mode when the previous action (download + install) fails but its not caching it.. Im wondering if there is another way to do this, or resolve it with a future patch?

Basic idea of my Job queue:
Download + install
If previous action fails goto label: disable-cache
Reboot
..
..
..
Label: disable-cache
Disable cache
Download + install
Reboot
..

[doug]

I’m happy to hear that you love the app! That’s great news.

You said “However, my Job queue is set to disable cached mode when the previous action (download + install) fails but its not caching it.”

It’s hard for me to decipher exactly what you mean here. My best guess is that you mean to say “it’s not catching it” (as opposed to “caching it”), and you mean that the ‘Label:disable-cache’ is never getting executed. Is that correct? If I’m understanding correctly, that would make sense to me. BP is looking for a failure where the action fails to execute altogether. In the case that you’re describing, BP executes the action successfully, but inside that action at least one update fails to install. We don’t consider a failure to install an individual update a failure to execute the action. A failure to execute the action would occur if, for example, the target computer was not reachable at all, or if the search for updates failed to execute. But in this case the overall process of checking/downloading/installing runs to completion, but one of the updates fails to download/install.

For your situation I would recommend that you simply do not use cached mode at all in the first place. If you’re going to be disabling cached mode for just that one update each month, there is little reason to use cached mode in the first place anyway, as that one update is the large, cumulative update. The issue with getting that particular update installed with cached mode enabled is not something we have any control over at this time. Microsoft would have to change the url structure in the metadata in order for that update to be installable under online cached mode. (more details about that situation here: cached-mode-and-updates-not-downloading-to-the-local-update-cache-directory)

Another option is to change your job queue to something like this:

(assuming you have cached mode enabled globally)
-Download and install
-Reboot
-Disable cached mode
-Download and install
-Reboot

This would give you what you want. It wouldn’t trigger based on a failure but it would effectively give you what you need because you’ll install the updates that are able to install with cached mode enabled, and then you’ll disable cached mode and install whatever updates are remaining.

As for anything that we can do/change in the code to cause the ‘If previous action fails’ method to detect the process as a failure when one of the updates fails to download/install even though the overall process itself executes successfully to completion… I’m not sure. We’ll have to discuss here to see if making any changes to this behavior is something that we think makes sense to do. Currently the behavior is expected/correct. I understand why it might not be what you were expecting to happen, but it isn’t a bug per se. We’ll talk about ways that we might be able to improve this experience or add more flexibility/control. Thanks for highlighting it.

-Doug

[spruitt]

Thanks Doug! That is helpful, I figured cached mode was a little faster. The job queue you mentioned makes more sense at the moment.

Appreciate the reply.

[Author]

Posts