URGENT: Impossible to retrieve a transformed XML/MPP using GetTaskDocumentWithFormat

Hi there,

we are using the GetTaskDocumentWithFormat function to transform MPP to XML, and we are getting a 502 Bad Gateway error with the following message:

“Error: GetTaskDocumentWithFormat. Exception: AmazonS3 Storage exception: One or more errors occurred”

It appears to be some internal issue with the storage of the file. The upload succeeded, but it is impossible to retrieve the file afterward.

Please have a look, this is affecting all of our users rn!
Thanks

Update: It may actually already fail earlier, specifically when the file is uploaded, there is no api logs from today. The error message I posted in the OP is from Friday already.

Still, this is majorly affecting our platform, help is urgently requested!!

@lasse.steffen ,
we will check the logs and return with the answer.

Does this happen with a specific file, or any file?

Hi, thanks for looking into it!

It happens with any file, we tried both .xml and .mpp in different sizes, and the task file “upload”, “copy” and even “move” all hangs indefinitely

A few things we noticed that we tried from the Tasks API docs:

  • GET returns application/octet-stream while the request only accepts multipart/form-data, so it gets stuck
  • DELETE is documented as returning JSON but comes back as 200 with no body → also stuck if the request is sent with the accept: application/json header

Upload, copy and move might have something similar going on, but they are not documented, so it is hard for us to tell what the request should look like

We have investigated further on our end and it seems that uploading a file through the PUT /v3.0/pdf/storage/file endpoint works and ends up in the same storage.

Another thing that we found is that when calling the GET /v3.0/tasks/{name}/format endpoint, using x-aspose-client or even x-aspose-client-version causes the request to hang indefinitely (also if there are other headers exist e.g. tracing headers).

We encountered this issue when using the Node.js SDK version 25.11 as well as 25.12 - but direct http calls to those endpoints are also not working.

Would really appreciate if you could give us an update on the investigation status as this affects our users. Let me know if you need further info from my end and I’d be happy to give more details!

@lasse.steffen ,
For your account, we found 3 error entries with the message:
“Error: GetTaskDocumentWithFormat. Exception: AmazonS3 Storage exception: One or more errors occurred”
which occurred on:

  • 2026-09-04T14:41:31.1839421Z
  • 2026-09-04T14:42:05.228931Z
  • 2026-09-04T14:42:21.9942613Z

This appears to be short-term infrastructure issues.

Could you please provide additional timestamps or RequestIds so we can investigate further?

I will add this info to the investigation ticket.

Just tried to call these endpoints again today and still timing out. Added some timestamps so they help you trace these on your side. Since no response were returning, wasn’t able to retrieve the requestId:

  1. Upload
PUT /v3.0/tasks/storage/file/{path}?storageName=internal_storage
Content-Type: application/octet-stream
  • Started: 2026-09-10T07:09:06.985Z

The only way we could get a file into storage at all today was through the
dashboard’s own uploader (or through the pdf upload endpoint).

  1. Recalculate
PUT /v3.0/tasks/{name}/recalculate/project?storage=internal_storage
  • Started: 2026-09-10T07:11:12.418Z

Also hangs, had to cancel manually

  1. Format
GET /v3.0/tasks/{name}/format?returnAsZipArchive=false&storage=internal_storage&folder=&format=mpp
  • Started: 2026-09-10T07:11:50.422Z

Hangs with those params, works after removing returnAsZipArchive and storage query params

For more context: we’re using Aspose’s internal storage, we also tried to use our own S3 storage and it seems that the issue stays. Please try to call your own endpoint to see if you could reproduce it as I saw in the other thread that it affected other users too so this must not be related to my account

@lasse.steffen ,
we’ve reproduced the upload problem and are working on the fix.