ManagedInstallReport.plist InstallResults key records download_kbytes_per_sec key as 0 for items installed from MSC

[nmcspadden]

REPRO STEPS:

1. Open up MSC
2. Click "Install" on an optional install
3. Watch ManagedInstallReport.plist

ACTUAL BEHAVIOR:
4. After the item is successfully installed, ManagedInstallReport.plist contains an InstallResults key that looks like this:

	<key>InstallResults</key>
	<array>
		<dict>
			<key>applesus</key>
			<false/>
			<key>display_name</key>
			<string>TextExpander 6</string>
			<key>download_kbytes_per_sec</key>
			<integer>0</integer>
			<key>duration_seconds</key>
			<integer>2</integer>
			<key>name</key>
			<string>TextExpander6</string>
			<key>status</key>
			<integer>0</integer>
			<key>time</key>
			<date>2020-01-13T02:44:29Z</date>
			<key>unattended</key>
			<false/>
			<key>version</key>
			<string>6.5.2</string>
		</dict>
	</array>

The download_kbytes_per_sec is always 0.

EXPECTED BEHAVIOR:
The downloaded_kbytes_per_sec should contain the average download speed from the download run, and generally be ignored for locally cached items.

WHAT I THINK IS HAPPENING:
Downloading and installing an item from MSC is technically two Munki runs: one to do a manualcheck, and one to do an installwithnologout type run. However, when doing an install via MSC, the postflight script is not executed in between the download and install - but the calculation of download speed is done when the item is already cached. This is resulting in an erroneous value of 0 for any item downloaded this way.

Normal automatic unattended updates don't seem to suffer this issue if the item is downloaded and installed successfully.

[gregneagle]

This is not a bit of data I pay any attention to (pretty sure the Google folks added it) so it's really low on my list of things to work on (or care about). I'd take a patch to fix the behavior to whatever works for you.

I'm confused, though, by your mention of "postflight script", which implies the Munki code isn't doing the calculations at all, but it is rather left to a postflight script to do. That seems ... wrong.

[nmcspadden]

Sorry, to be clear, the postflight script I have reads the ManagedInstallReport.plist and reports the data to a logging endpoint - like an internal Sal. It doesn't do any calculation by itself.

[gregneagle]

So you are implying the issue is actually that the data doesn't get posted after the download. I'm fairly certain we suppress the postflight script run in the middle of that workflow (user choosing an item to install) to speed things up for the user so they get their desired result faster. Adding another postflight script run will just slow things down and lead to poorer UX.

Feels like a deeper discussion needs to happen, and not just a quick "patch".

[nmcspadden]

Right, the issue is that the download speed is calculated after the download, but the actual result isn't made available at the end of the install process. The "patch" might be to simply carry the value along if the same item was previously detected as downloaded, but I haven't looked into the complexity of it.