CON-1184 - Failed-Network error when exporting form entries from Contour

Review notes with 3.0.29 I was unable to replicate but was able to confirm the missing response header 'Content-Length'

A nightly build has been created here http://nightly.umbraco.org/?container=umbraco-contour

UmbracoContour.package.3.0.30.WIP-Build.1.V4.zip
UmbracoContour.package.3.0.30.WIP-Build.1.V6.zip
UmbracoContour.files.3.0.30.WIP-Build.1.zip

@DanDiplo if you could install this nightly containing this fix please and let me know if this now resolves your problem. (Please backup files & DB, as always when preforming any upgrade)

@warren.buckley Thanks for looking at this so quickly. It is a strange issue, as it only seems to affect the live site of the client, and not the development version. The only difference between the two is the number of form entries. This may be why you couldn't reproduce?

Anyway, the good news is that I installed UmbracoContour.package.3.0.30.WIP-Build.1.V4.zip and this did indeed fix the issue. I can now export all form entries using Chrome (I also tested before the upgrade to confirm the issue was still present in latest Chrome, which it was).

I'm not sure what is in 'UmbracoContour.files.3.0.30.WIP-Build.1.zip' but I didn't install that package. I basically merged the binary files and user controls from v4.zip into the site in question.

Hi @DanDiplo The V4 is an Umbraco package for V4 sites & V6 aimed at Umbraco V6 and the final files ones is just a zip designed to be unzip over the top of your site.

I am glad that this fix has worked for you.

Today 3.0.30 has been released which contains this fix.

Hi @DanDiplo can I ask why you have re-opened this please?

Hi @frank.eddy can I ask why you have re-opened this issue please? What problems are you having with this?

Just tested 3.0.30 in our Umbraco 7.4.3 staging environment, exporting all to CSV still fails. Using Chrome 54.0.2840.71 m (64-bit) on Windows 10 returns "Failed - Network error". Using Firefox 49.0.2 it does not return all rows, only 183 of 359 in my test.

@warren.buckley, unfortunately we are still seeing "Failed - Network error" on Chrome and from browser console I see "Resource interpreted as Document but transferred with MIME type application/octet-stream: "http://testing.internal.pvt/umbraco/plugins/umbracoContour/exportFormEntriesDialog.aspx?guid=902508e9-b7f5-4d0c-9e2e-2b5ce9faed45"."

@warren.buckley, more troubling is when it does work, we get incomplete exports.

Sorry to hear this @frank.eddy I will need to try to reproduce this & confirm this problem with you, before I can 'offically' re-open this task.

Have you tried this in other browsers such as IE11 or Edge to see if you get varied results. Can you offer any further insight for me please, that can help to get to the bottom of this problem with you.

Thanks Warren :)

@warren.buckley, Test using IE 11.0.10240.17713 also fails, and even though I'm using Windows 10 I don't have Edge. See screenshot. We've had problems with exporting for some time, particularly with the export not including all rows. We recently upgraded from Umbraco 6.1.6 /w Contour 3.0.28 to Umbraco 7.4.3 /w Contour 3.0.29 with hopes the upgrade would fix the problem. The host we're running on is Win 2012 (not R2) Standard /w IIS 8.0 that is fully patched and up-to-date.

I've watch the UmbracoTraceLog and EventView Application logs as we test, and I don't see any new entries.

What other information can I provided that might help?

@warren.buckley, did some deeper digging using WireShark. On all three browsers (Chrome, Firefox and IE) the data download definitely starts. I can see the data on-the-wire being sent to the browsers. However the data stream abruptly and unpredictably stops. And when it does, Chrome and IE error, and FireFox saves an incomplete file to the local file system.

Questions,

1. By chance are you closing the response? (see https://blogs.msdn.microsoft.com/aspnetue/2010/05/25/response-end-response-close-and-how-customer-feedback-helps-us-improve-msdn-documentation)

2. Is the export file been generated and saved temporary on the server before sending it to the client?

@frank.eddy how long do you get before the connection is interrupted or aborted. Wondering if it's effectively taking too long, timing out or similar & connection is being aborted.

Have you tried this on a different environment, such as local, dev, staging/uat to confirm it's not environment specific.

Also does this happen with only a specific form or all forms on the site? Does this form have a large amount of entries/submissions that its trying to export?

I will look into the code now in regards to your questions & update you shortly.

Another question why I still do some investigation @frank.eddy have you tried the other export types such as HTML or XML to see if they work at all please?

OK @frank.eddy I have to hold my hands up and admit I made a mistake, the 3.0.30 build published on our.umbraco did not have the branch merged in & got slipped through the usual process of PRs being made for a GitFlow workflow.

Above in this thread I created a nightly build of that specific branch containing that fix but since getting the OK this never got merged back in.

I apologise for the inconvenience & this has now been updated on our.umbraco.org as 3.0.31 alternatively grab them from http://nightly.umbraco.org/?container=umbraco-contour

Thanks, Warren

I will pull the update an test shortly. Thankyou!

@warren.buckley @warren.buckley, I see you note that there is a new build, but to answer your question it fails for all types CSV, HTML, XML and the number of rows also does not seem to matter. It fails on an export that only consists of 2 rows.

@warren.buckley, Our preliminary testing looks very promising for we are able to export all rows for all formats. We are going to run it through our entire QA test cycle to confirm. Hopefully we'll get though that shortly. I'll provided additional feedback as soon as we're done. THANK YOU for your prompt attention to this!

@warren.buckley, Our QA team has confirmed that 3.0.31 fixes the problem. Thank you again!

@frank.eddy I will now then set this back to fixed.