In the normal scenario when things are working, we would get a gzip file from the DssStreamResponse with something like the following code:
RawExtractionResult extractionResult = extractionsContext.ExtractRaw(extractionRequest);
// we set awsDownload to true
if (awsDownload) { extractionsContext.DefaultRequestHeaders.Add("x-direct-download", "true"); }
DssStreamResponse streamResponse = extractionsContext.GetReadStream(extractionResult);
using (FileStream fileStream = File.Create(gzipDataOutputFile))
{
streamResponse.Stream.CopyTo(fileStream);
}
However, in the odd occasions, the file we get from the stream response is actually an html file. (And when I opened the html file in a web browser, it would redirect me to downloading the actual gzip file.)
Is this a bug in the api? Or is there something that I might not be doing properly here?
3
●0 ●2 ●8
In odd occasions, the file we get from the stream response is actually an html file -TRTH
23k
●22 ●9 ●14
Hello @Prathibha.Mariyappa,
I have not, personally, seen this happen, but to me such discrepancy in behavior would seem to indicate a rare-to-reproduce TRTH service side issue, rather then an incorrect REST API usage.
Would not it be a logical step, at the exact time when this suspected issue is detected, to collect all the info including job ID, extraction notes, output and any other relevant info and submit it for detailed investigation by TRTH development via TRTH product support?
I would appreciate if you could post the follow-up with any relevant info that is found, as an answer, or at least a support case number as a comment, I would be interested to learn more about the occurrence.
I will be on the lookup for it as well, and will supply more info into investigation in progress if I see it happen.
Perhaps if other members reproduce, they will supply more info into this question as well, with these kind of rare-to-reproduce scenarios, more info and info while-still-occuring can potentially be very helpful, in my experience.
