Can't download added software

[marko-lisica]

Fleet version: Fleet 4.50.0 • Go go1.21.7

Web browser and operating system: Google Chrome 125.0.6422.112

---

💥  Actual behavior

When I open software that's added by user, it can't be downloaded from UI.

• For one software I get an error message (see screenshot)

- For another software it works, but there's a big delay from clicking on the download button until the download actually starts. ### 🧑‍💻  Steps to reproduce

1. Open "Microsoft Remote Desktop v10.9.6" software and click download (I get error)
2. Open "Google Chrome" software and click download button (download is delayed, so it looks broken)

[PezHub]

@marko-lisica I'm not seeing the MS Remote Desktop.pkg in Dogfood under workstations anymore. Did you delete it? I don't see anything in the activity feed but I did confirm i created it 5 days ago -

Gabe Lopez added Microsoft Remote Desktop v10.9.6 (Microsoft_Remote_Desktop_10.9.6_installer.pkg) software to the 💻 Workstations team.
5 days ago

I could have sworn I deleted it when done so maybe that's where the bug is. I'll try and reproduce

[PezHub]

2nd issue - confirmed there's zero indication the file is downloading and when dealing with large installers the user will have no idea its occurring in the background.

First issue - I haven't been able to reproduce on my local instance with two different users but I'll keep trying.

I uploaded and deleted Crowdstrike to the Workstations Team in Dogfood. Do you still see it @marko-lisica?

[marko-lisica]

I'm not seeing the MS Remote Desktop.pkg in Dogfood under workstations anymore. Did you delete it? I don't see anything in the activity feed but I did confirm i created it 5 days ago

@PezHub I think it's removed via GitOps. All software was uploaded via UI so GitOps run removed it since there's no software specified in our repo.

Could you try to add Microsoft_Remote_Desktop_10.9.6_installer.pkg again and see if it can be removed?

2nd issue - confirmed there's zero indication the file is downloading and when dealing with large installers the user will have no idea its occurring in the background.

I think we'll need to bring this to the product team and find some solution (loading state perhaps).

[gillespi314]

@marko-lisica, it would be helpful if you could pop open your browser dev console and see if there are any errors being logged there as well as any errors for the download requests in the network tab. That will help us identify if the error is occurring on the backend or frontend (it's hard to know without that since our flash message is currently just a generic error).

[PezHub]

successfully added & removed Microsoft_Remote_Desktop_10.9.6_installer.pkg to Workstations in Dogfood.

I re-added it and left it to see what happens once GitOps runs.

[marko-lisica]

@gillespi314 This is what actually happens. You can try it yourself with Microsoft Remote Desktop. The request lasted for 2 minutes and then was interrupted.

cc @PezHub

[mna]

I did test this out with the Network tab open on dogfood, the Microsoft Remote Desktop installer wasn't there anymore but I tested with Zoom Workplace and I see the long 14s delay before anything visual happens, and then the download is available (124MB).

I think there could be a frontend fix as mentioned, but there may also be a possible backend improvement to send the download in "chunked" transfer mode, instead of one big response. I believe this could perhaps make the browsers give a more immediate "download in progress" indication, I'll give it a shot (maybe the best solution will be a combination of both, but we'll see).

[mna]

Ah well, http/2 does not support chunked transfer-encodings anymore, and I couldn't find a way to transfer it from the backend so that it would start the download indication sooner. I'm afraid it will have to be a frontend-only fix to add some feedback that the download is starting soon?

[mna]

Found this that seem to indicate it could work with http.ServeContent, but the problem is that it is very hard to get access to the HTTP Request object (which is a required argument to ServeContent) in our endpoint handlers due to the framework that we use, so I haven't gone down that rabbit hole: https://rafallorenz.com/go/go-http-stream-download/

[roperzh]

if helps, we fixed this for bootstrap packages by using native browser downloads instead of JavaScript. It is a tiny more involved than the current approach. The main problem is that the request is authenticated using a header, so you can't use something like <a download href="...">

Instead, we use a <form> with a hidden input that sets the token

fleet/frontend/pages/ManageControlsPage/SetupExperience/cards/BootstrapPackage/components/BootstrapPackageListItem/BootstrapPackageListItem.tsx

Lines 25 to 51 in 2e54f95

	/**
	* This component abstracts away the downloading of the package. It implements this
	* with a browser form that calls the correct url to initiate the package download.
	* We do it this way as this allows us to take advantage of the browsers native
	* downloading UI instead of having to handle this in the Fleet UI.
	* TODO: make common component and use here and in DownloadInstallers.tsx.
	*/
	const DownloadPackageButton = ({ url, token, className }: ITestFormProps) => {
	return (
	<form
	key="form"
	method="GET"
	action={url}
	target="_self"
	className={className}
	>
	<input type="hidden" name="token" value={token || ""} />
	<Button
	variant="text-icon"
	type="submit"
	className={`${baseClass}__list-item-button`}
	>
	<Icon name="download" />
	</Button>
	</form>
	);
	};

[ghernandez345]

@mna @roperzh im gonna look into fixing this the way Roberto mentioned above. I'll let you know how it goes

[mna]

Following a chat with @ghernandez345 and @roperzh , and as alluded in other comments on this ticket, it appears there are two issues:

• sometimes the download results in a 500, which seems to be this:

runtime error: invalid memory address or nil pointer dereference


6 library frames
software_installers.go in orbitDownloadSoftwareInstallerResponse.hijackRender at line 194
transport.go in encodeResponse at line 43
server.go in Server.ServeHTTP at line 132
instrument_server.go in InstrumentHandlerRequestSize.func2 at line 255

• sometimes it succeeds, but there is no visual indication that the download is in progress until it is fully done (and can take multiple seconds since some installers are quite big), this would require a UI change to add a notification.

I will take care of fixing the backend 500, and Gabe will work on the UI change.

[mna]

Backend fix here: #19527

@ghernandez345 feel free to move the ticket as per the frontend work, the backend effort was minimal.

[PezHub]

• confirmed the browser's native downloads UI now tracks the download progress in Chrome, Safari and Firefox.

• Note: the other error mentioned at the top of the thread was related to the S3 bucket config for Carves set to delete files after 24hrs, thus creating a ghost file. This issue is being addressed here Lifecycle on carves bucket deletes software installers #19526

QA Approved!

P.S. I did some additional testing while throttling my connection speeds and consistently got the failed to parse multiple form error, but that is being tracked separately here FYI

[fleet-release]

Download troubles faced,
Fleet's updates will bring grace,
Swift, error-free space.