How to handle client abort / disconnect while uploading multipart file

[hermantolim]

Summary

Hello, i am trying to handle a client abort upload on axum multipart form data, currently, there is no way to know the client side status, in js we would have event to handle abort signal, and cancel the upload completely, by removing the file in temporary folder, or in my case I proxy the upload to s3 multipart upload, and using the tokio-utils to turn the field into StreamReader so i can upload it to s3 part by part, here is a snipped of my codes:

while let Some(field) = multipart.next_field().await? {
    // Extract the file name from the field
    let filename = field.file_name().unwrap_or("unknown_filename").to_string();
    let content_type =
      field.content_type().unwrap_or("application/octet-stream");

    println!("=============================================");
    println!(
      "Received file: {} with content type: {}",
      filename, content_type
    );

    let key = format!("uploads/{}", filename); // Use the filename as the S3 key
    // s3 uploader, wrapping aws-sdk-s3 client
    let mut uploader = Uploader::new(&state.s3_client, key).await?;
    let mut part_number = 1;

    // Use StreamReader to convert the field into an AsyncRead-compatible stream
    let byte_stream =
      field.map_err(|e| std::io::Error::new(std::io::ErrorKind::Other, e));

    let mut stream_reader = StreamReader::new(byte_stream);
    let mut buffer = Vec::new();

    loop {
      let n = match stream_reader.read_buf(&mut buffer).await {
        Ok(0) => {
          println!("stream reader receive EOF");
          break;
        }, // EOF
        Ok(n) => {
          println!("stream reader receive {} bytes", n);
          if buffer.len() >= Uploader::MIN_PART_SIZE {
            println!("buffer equal or greater than min part size upload part");
            uploader
              .upload_part(part_number, buffer.split_off(0))
              .await?;

            part_number += 1;
          }
        },
        Err(err) => {
          eprintln!("Error reading file {}: {:#?}", filename, err);
          let abort_res = uploader.abort().await;
          eprintln!("abort upload: {:?}", abort_res);
          return Err(Error::bad_request());
        },
      };

    // Upload the last part if any remaining data is smaller than 5MB
    if !buffer.is_empty() {
      println!("buffer not empty continue upload part");
      uploader.upload_part(part_number, buffer).await?;
    }

    let res = uploader.complete().await?;

    println!("{:?}", res);
    println!();
  }
  Ok(())

not sure where i can detect the disconnection or abort signal from client

### axum version

0.7.5

[mladedav]

If the client disconnects, your handler will be aborted, i.e. not polled anymore. You need to either spawn your operation with tokio::spawn to continue running after that happens or you can use a drop guard to find out when this happened.

[hermantolim]

the problem with my case is in the loop, not sure why, if i didn't specify a timeout within the loop, the loop run indefinitely causing the worker to be occupied by the loop, making ctrl+c signal, etc, not working. my current work around is to add a timeout to forcefully terminate it

[mladedav]

How do you know the loop runs? Is it still printing output?

If this is inside an Axum handler, it is a task spawned in background so it shouldn't have any effect on ctrl c or anything like that.

Can you create a minimal example of your issue?