Progress from 0 to 0.999 to 1

[Sh4dord]

Describe the bug I want to track the progress of downloading / uploading I set onProgress callback and Updates.statusAndProgress

But onProgress callback is only called with a progress of 0.99 when the task status set to running and to 1 when the task is completed

I also test with another link like : https://testfile.org/ and it's work well I don't know if the content length is get by the HEAD method or if it can be gotten by the Downloading one.

Previously I used :

unawaited(
          _handleListeners(
            bodyStream,
            response.contentLength,
            completer,
          ).onError((error, stackTrace) => null),
        );

Where the response is given by http.dart package, that contain the bodyByte stream. And the progress was obtained by :

bodyStream.tap((chunk) {
          totalSoFar += chunk.length;
          onProgressUpdate(chunk.length, totalSoFar, contentLength);
        });

Expected behavior Does the expected behavior is not a smooth progress between 0 to 1.0 ? I also see that expectedFileSize is set to -1 but I already have the expectedSize of the file and also the Content-Length in the download response.

Logs If possible, include logs that capture the issue: Log inside the onProgress and status of onStatus

[Repository] (INFO) Status of download_368114_0_22_1784662_0_1784662 at TaskStatus.enqueued
[Repository] (INFO) Status of download_368114_0_22_1784662_0_1784662 at TaskStatus.running
[Repository] (INFO) Downloading of download_368114_0_22_1784662_0_1784662 at 0.999
[Repository] (INFO) Downloading of download_368114_0_22_1784662_0_1784662 at 1.0
[Repository] (INFO) Status of download_368114_0_22_1784662_0_1784662 at TaskStatus.complete

Code Just a basic DownloadTask, POST method a post content, updates: Updates.statusAndProgress.

If you need more info to help me don't hesitate to ask, I will try to answer quickly. Thanks for your help

[781flyingdutchman]

If the expected file size is set to -1 then that indicates that the server does not provide proper content length headers to determine the file size. You can supply your own content length using the Range or special Known-Content-Length headers (see the docs in section Progress) to force the use of that content length in progress reporting.

[Sh4dord]

If the expected file size is set to -1 then that indicates that the server does not provide proper content length headers to determine the file size. You can supply your own content length using the Range or special Known-Content-Length headers (see the docs in section Progress) to force the use of that content length in progress reporting.

Thanks for your answer. I put the Range OR Known-Content-Length, with the size of the file nothing append On the void _emitProgressUpdate(TaskProgressUpdate update) function expectedFileSize is to -1 even if I call await task.expectedFileSize().

I join 2 images, I had to hide some info about the post content.

I Also tried with 'Range' : '0-83480589'

Here I stopped 2 times in the void _emitProgressUpdate(TaskProgressUpdate update) function, one for progress 0.0 and an other for the progress 0.99.

Another bug

The first time I try to set 'Known-Content-Length' AND 'Range', Then I also try to call await task.expectedFileSize() , but from this step, now the download was enqueued but not running at all... Event if I reverse the changes and destroy the FileDownloader() download was just enqueued.

[Repository] (INFO) Status of download_368114_0_22_1783249_0_1783249 at TaskStatus.enqueued
[Repository] (INFO) Status of download_368114_0_22_1783241_0_1783241 at TaskStatus.enqueued
[Repository] (INFO) Status of download_368114_0_22_1783240_0_1783240 at TaskStatus.enqueued

How I can fully reset the queue without uninstalling the app ?

[781flyingdutchman]

You cannot purge enqueued background tasks entirely (though on Android killing the app may do the trick, depending on OEM), and any time you reuse a taskId (even a very old one) all bets are off, as it messes with state management. Other than that, I don't know how to help you - my sense is that these issues are caused by how your server manages downloads, and beyond the 'Known-Content-Length' and 'Range' hacks there is not much you can do about that.

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity.