URGENT: Server Error in '/v1.1' Application

Aspose.Total Product Family
1

We get server errors and none of the calls works anymore. See the html file attached.


The errors are there for 1hr now already according to our logs, they started coming in at 11:30h (GMT+02:00).
2

Hi,


Our team has checked but was unable to find any issues with the cloud service Can you please try again and let us know if you are still facing the same errors?

Thanks,
3

We get errors in the Words component regarding the “splitDocument” calls. We validated these errors using multiple different servers.

  • Document is uploaded, which seems to be okay
  • Words ‘statistics’ is called, which seems to be okay
  • The document is split to .png files, which returns errors
  • The document is split to .html files, which returns errors
To me it looks like the errors we get are not reported to the support team. Errors like these should throw errors at your side, this isn’t something that should be initiated via the customers right?

And, please give us a reply from the moment you start investigating it. Now it took three hours to get any response.
4

Hi Richard,

We are investigating it further and will update you shortly. We are sorry for the inconvenience.

Best Regards,

5

Hi Richard,

We have started the investigation before you posted here on the issue because our systems reported it.

The general problem with all api calls down was fixed, now we are investigating your problem related to the words API.

Can you please provide the AppSID you are using ?

Thanks and we are really sorry for the incovenience,
Daniel Gherasim

6

Hi Daniel, thanks for the update on the progress. Hereby our PROD sid:

1ee26174-a1c7-4847-ae29-9d46fabb1d04
The error html we get can be found in attachment “html.rar”.

The errors are not shown in our usage log though.
7

Hi Richard,

Sorry, we were not able to notice this issue even with your account. We tested some documents with a test account and everything was working fine. One of your documents was tested with your account and it did not produce any error.

We were able to notice 'Specified cast is not valid' error while splitting one of your documents to HTML but same document was split to PNG without any issue. This is not a general issue and issue is related to a specific document only. Such issues will be fixed in Aspose.Words API. We will log the issues you reported in several new threads (if reproduced) and update you in the respective threads.

Can you please test again and share if you are able to reproduce this issue with some specific documents only, or all of your split requests are generating the same server error?

Best Regards,

8

Hi Muhammad,


Thanks for the update. We tested our same codebase on PROD, QA and DEV environments and none of them works (read: all return same error).

Next to that we have a local test project to test Aspose documents outside of our application context, even that one does return an error. We make use of the PHP SDK via the Symfony Bundle with the following lines of code:

/** @var Folder $folder /
$folder = $this->container->get(‘aspose.storagefolder’);
$folder->uploadFile($this->fileFolder . $filePath);

/* @var Document $document */
$document = $this->container->get(‘aspose.wordsdocument’);
$fileInfo = pathinfo($filePath);
$document->setFileName($fileInfo[‘basename’]);

$options = array(
    ‘format’ => ‘html’,
    ‘zipOutput’ => ‘true’,
);
$zipResult = $document->splitDocument($options);
var_dump($zipResult);

So, can you validate the format and zipOutput parameters work for you as well? Yes, all our split calls are having these errors and is costing us lots of customers already.

And no, this is not related to the documents I’ve reported earlier today and yesterday. Those just were the errors we got over the last six weeks.
9

I’ve been debugging this a bit further, and the error is with downloading the .zip file after splitting. So, the splitting is okay but downloading a file using Folder does not work.

Basically downloading the result from the split call errors, using cURL for a GET-request to the following unsigned URL trigger the error:
http://api.aspose.com/v1.1/storage/file/http://api.aspose.com/v1.1/words/67559%20-%20vergeleken%20document%20Word%20based%20on%20Word%20level.html.zip?appSID=&signature=

Edit: after 1.5h of no response I did take a look at the problem again, and found out what happened. Since the morning the API is returning absolute URLs where it did return relative URLs before. This is a BC break and should be fixed asap, especially because the URL itself is incorrect and should be something with “/storage/file” in order to download it.

{#198 

+“SourceDocument”: {#199 

+“Href”: “http://api.aspose.com/v1.1/words/AOD CARMEN FRANCISCO 23-03-2016.docx”

+“Rel”: “self”

+“Type”: null

+“Title”: null

}

+“Pages”: array:147 

+“ZippedPages”: {#347 

+“Href”: “http://api.aspose.com/v1.1/words/AOD CARMEN FRANCISCO 23-03-2016.html.zip”

+“Rel”: “zippedpages”

+“Type”: null

+“Title”: null

}

}
10

Hi Richard,

Can you please try using the basename function to extract the file name from the ZipedPages->Href uri?

Best Regards,

11

Hi Richard,

This is to update you that our platform team is also investigating why the output URI has changed which produced this issue at your end. We will keep you updated about our findings.

Best Regards,

12

Hello Muhammad, I understand that would fix the bug but basically the answer is a huge no because we are not willing to make dirty workaround fixes for bugs that you guys introduced without properly testing them. This is something that might affect all Aspose Cloud results so should be fixed API-side.


So please fix this asap, or show me any documentation where we should have seen that this “planned deprecation” was coming. It took me thirty minutes to completely debug this problem, so I’m sorry but every minute it takes starts me questioning how you guys actually debug such issues.
13

Okay great news on the output URI, please keep us up-to-date.

14

Hi Richard,


We will update you here as soon as there are any developments to report.

Thanks,
15

Hi Richard,

Even if we change the API to return the same response (as it was returning before the latest changes), it is highly recommended to use basename with all Href values that you use as file names. This will make your code more stable and it will keep working in such cases.

Best Regards,

16

Hi Muhammad, then that’s something you should build in your SDK before putting such a major change into production. We will update you once we tested and released our own hotfix.


Edit: Using the basename does not solve the problem, after testing our fix it seems that since yesterday morning all files are stored in a subfolder. As you can see in the file I’ve attached, there even is a folder with a colon, a character that is not allowed. So, the files are stored in the wrong location. This could also explain the incorrect URL, because that some sort of reflects the path where the files are stored.

Adding this path to the “download file” call hardcoded does not allow us to download the file either, so this can not be resolved from our side and should be fixed on the API-side asap.
17

I’ve contacted Australia office by phone, which informed me to contact support. Again 1.5h and so far still no response. Please contact us by phone ASAP in order to discuss this urgent matter: +31 13 822 3424

18

Hi Richard,

Our product team is fixing it. It will be fixed soon. We will update you as soon as it is fixed.

We are extremely sorry for the inconvenience.

Best Regards,


19

Hello Muhammad, it has been three hours so please provide us with an update asap. We propose you rollback the version that still was working before yesterday morning 11am, or you provide us with a reliable ETA for the fix.

20

Hi Richard,

We have done the same. Changes have been rolled back to previous version. It took some time to roll the changes back. Previous version is live now. You may test again and share if you still see any issue.

Sorry again for the inconvenience.

Best Regards,