Hi Selvarani,
The most likely cause is not the Download File activity, but that the old FileDocument metadata exists while the actual binary content cannot be retrieved correctly from the file storage.
Mendix stores the FileDocument data separately from the normal entity data; the file content is handled through the application's file/blob storage.
Since:
HasContents = trueI would suspect corrupted/missing/inaccessible binary content for that particular old FileDocument, or an issue with the underlying file storage. HasContents = true by itself doesn't prove that the binary can actually be successfully streamed.
The Upstream Prematurely Closed connection message means the connection was terminated while the response/file was being transferred. Mendix also documents similar premature-connection errors around file transfers.
First, test whether other old FileDocuments uploaded around the same period also fail.
Also test the file using a standard File Manager or Download File activity. If the newly uploaded file works through exactly the same flow, that further confirms the problem is with the old file's stored content rather than your microflow.
I would not try to fix this by changing HasContents or directly modifying the database. If multiple existing files are affected, provide Mendix Support with the affected FileDocument IDs and the exact timestamp/logs of a failed download so they can investigate the underlying storage.
Kindly mark this as the accepted answer if it helps.