Download document pdfs is opening with error.

[abhim1509]

We are trying to download pdfs, I am sending binary data to frontend, however as soon as we open downloaded pdf, it pops up with error "We cant open this file. Something went wrong".
Attaching the screenshots for reference. Kindly provide some suggestions on the _same.
Have already looked in backend example citation and API documentation viz.
https://github.com/docusign/code-examples-node/blob/master/lib/eSignature/examples/envelopeGetDoc.js
#255
https://developers.docusign.com/docs/esign-rest-api/how-to/download-envelope-documents/

sample-documents (13).pdf

[InbarGazit]

what do you pass for documentId?

[abhim1509]

I have tried with the documentId, "combined" value.
This is the current implementation with multiple documents and their documentIds:
let documentsList = await envelopesApi.listDocuments(
accountId,
envelopeId,
null
);
const downloadedDocuments = await Promise.all(
documentsList.envelopeDocuments.map(async (document: any) => {
return await envelopesApi.getDocument(
accountId,
envelopeId,
document.documentId,
{}
);
})
);
return downloadedDocuments;
Here is the response in frontend..

[abhim1509]

@InbarGazit looking for your valuable inputs.

[andercs]

@InbarGazit Would like to chime in that we're also getting this error, although we retrieve our documents slightly differently than Abhinav mentioned.

async getDocument(envelopeId: string, documentId?: string) {
        const envelopesApi = await this.getEnvelopesApi();
        const options = {};
        // options.certificate = 'false';
        return await envelopesApi.getDocument(
            this.accountId,
            envelopeId,
            documentId ? documentId : 'combined',
            options
        );
    }

Interestingly, the completed envelope can be readily downloaded from the eSignature Web App, so it's certainly stored as a valid PDF somewhere!

[andercs]

Quick follow-on, the example using curl at https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopedocuments/get/ works completely fine. I get a valid PDF when I save the output to a file, so the endpoint itself doesn't appear to be the issue.

Example:

curl --request GET 'https://demo.docusign.net/restapi/v2/accounts/0cdb3ff3-xxxx-xxxx-xxxx-e43af011006d/envelopes/ea4cc25b-xxxx-xxxx-xxxx-a67a0a2a4f6c/documents/1/' \
       --header 'Authorization: Bearer eyJ...bqg' --output test_file.pdf

[andercs]

Possible SOLUTION, it looks like the logic for this SDK to run callApi and handle the application/pdf response type was written on February 18, 2016.

This looks to predate y'all's superagent dependency's implementation of an appropriate application/pdf response type handler, which didn't occur until October 2, 2017.

My guess is that at least some, if not all of the odd behavior is originating from the usage of a string to store the byte chunks rather than an array like in the most modern official implementation from superagent.

https://github.com/visionmedia/superagent/blob/master/src/node/parsers/image.js

compared to the following from this library's ApiClient.js

if (request.header['Accept'] === 'application/pdf') {
      request.parse( function (res, fn) {
        res.data = '';
        res.setEncoding('binary');
        res.on( 'data', function (chunk) { res.data += chunk; } );
        res.on( 'end', function () {
          try {
            fn( null, res.data );
          } catch ( err ) {
            fn( err );
          }
        });
      })
    }

Since I'm guessing upgrading from v3.8.2 of SuperAgent to the most recent of v8.0.0 would be an endeavor, I'd yoink their function from image.js above and drop in a thank you comment in the code for it, presuming it fixes this issue.

[andercs]

Because I don't leave well enough alone, yeah my above suggestion fixes it. There's 35 bytes different between using curl and using the SDK with my suggested fix, but I can't visually distinguish it and both PDF files open.

[InbarGazit]

See code in https://github.com/docusign/code-examples-node/blob/master/lib/eSignature/examples/envelopeGetDoc.js which work ok for me.

[InbarGazit]

  let mimetype;
  if (pdfFile) {
    mimetype = "application/pdf";
  } else if (docItem.type === "zip") {
    mimetype = "application/zip";
  } else {
    mimetype = "application/octet-stream";
  }

[andercs]

@InbarGazit the only part of that example we care about is the fileBytes / results object that gets returned at the very end. We do the

let dsApiClient = new docusign.ApiClient();
  dsApiClient.setBasePath(args.basePath);
  dsApiClient.addDefaultHeader("Authorization", "Bearer " + args.accessToken);
  let envelopesApi = new docusign.EnvelopesApi(dsApiClient),
    results = null;

  // Step 1. EnvelopeDocuments::get.
  // Exceptions will be caught by the calling function
  results = await envelopesApi.getDocument(
    args.accountId,
    args.envelopeDocuments.envelopeId,
    args.documentId,
    null
  );

without issue. The problem is when you write those result bytes to a "PDF" file, no PDF reader can open them. The file is corrupt.

We don't use a mimeType for anything so the code from the comment a few minutes ago doesn't help us. I did most of the analysis for you all and even made an MR with the fix, which I tested locally and it does in fact fix the corrupt PDF issue.

[andercs]

Also opened a support Case in the DocuSign Support site to get more visibility into the issue because it's going to be a major blocker for us that I'd rather not have to come up with a workaround for.

Case #: 10013266