File upload send progress goes too fast

[matthew-carroll]

Package

dio

Version

5.8.0+1

Operating-System

MacOS

Adapter

Default Dio

Output of flutter doctor -v

FYI - I'm using `dio` directly in Dart on Mac, not within Flutter.

Flutter 3.27.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 17025dd882 (8 weeks ago) • 2024-12-17 03:23:09 +0900
Engine • revision cb4b5fff73
Tools • Dart 3.6.0 • DevTools 2.40.2

Dart Version

3.6.0

Steps to Reproduce

Here's a code sample that I'm using to upload an mp4 audio file:

final client = dio.Dio();
    final response = await client.post(
      'https://myurl',
      options: dio.Options(
        headers: {
          "Authorization": "Bearer $authToken",
        },
      ),
      data: dio.FormData.fromMap({
        'file': dio.MultipartFile.fromFileSync(
          mediaFile.path,
          filename: basename(mediaFile.path),
        ),
      }),
      onSendProgress: (int sent, int total) {
        print('Send Progress (${(100 * sent / total).round()}): $sent/$total');
      },
      onReceiveProgress: (int sent, int total) {
        print('Receive Progress (${(100 * sent / total).round()}): $sent/$total');
      },
    );

Expected Result

The "send progress" reflects the amount of data sent to the server, at the rate it's actually being sent.

Actual Result

The "send progress" reflects the data that's loaded into memory, or otherwise processed on the client side. The progress goes way too fast. I'm stuck sitting at 100% for about a minute as my large audio file uploads to the server.

[AlexV525]

Could you help to build a reproducible example with httpbun.com ?

[matthew-carroll]

Are they gonna let me upload random files with 2 hours of audio data? In terms of the dio side, I've included exactly the relevant code.

Have you tried running a file upload with dio from a Mac CLI app? Or even a Mac Flutter app? Have you experienced the correct progress report using this API? It seems likely to me that this behavior is completely broken for everyone. If you haven't already, I would encourage you to try a file upload from a Mac and see what's reported on your end.

[AlexV525]

Are they gonna let me upload random files with 2 hours of audio data? In terms of the dio side, I've included exactly the relevant code.

Oh, that was unsure for sure. :)

Have you tried running a file upload with dio from a Mac CLI app? Or even a Mac Flutter app?

No, I'm not near my Mac.

Have you experienced the correct progress report using this API?

Yes, the callback used to work IIRC. The library uses the HttpClient as the underlying implementation, if the problem does not come from it, it should be some recent changes that break the behavior. I just glanced at our tests and unfortunately, we seem not to have proper tests about it.

If you haven't already, I would encourage you to try a file upload from a Mac and see what's reported on your end.

What I wanted to say is that the bug reporter is the one nearest to the repro environment, which would make it easy to provide a reproducible example.

[WeiJun0507]

Are they gonna let me upload random files with 2 hours of audio data? In terms of the dio side, I've included exactly the relevant code.

Have you tried running a file upload with dio from a Mac CLI app? Or even a Mac Flutter app? Have you experienced the correct progress report using this API? It seems likely to me that this behavior is completely broken for everyone. If you haven't already, I would encourage you to try a file upload from a Mac and see what's reported on your end.

I have a Flutter app running on a Mac that uses Dio to assist my application media download and uploading process. I'm using Dio version 5.8.0+1. This issue doesn't seem to appear on my side.

I did have your scenario as the progress isn't the actual binary transmission size to the end but the progress to transmit the file somewhere in local memory. But after that I realized that is because I have a local network proxy that will redirect the file from local to the actual ends for some security purposes.

Maybe you can double checked again whether the upload link you used has this kind of local proxy that lets the file binary transmit into the memory then only redirect to the actual ends?

[matthew-carroll]

I've contacted the podcast service asking them to verify what's actually happening during the request. I thought that perhaps they're uploading AND transcoding within a single request. If so, that would explain the discrepancy. I'm waiting to hear back from them.