Corrupt file attachments

We encountered an issue where a file download triggered via the Content-Disposition header will result in a link to download the file, but the file will be corrupt. A similiar issue is also documented in following swagger-ui issue:

https://github.com/swagger-api/swagger-ui/issues/4638

In our case we want to download a tar-file. So the content-type of the response is application/gzip. We want to add the download-endpoint to the swagger-documentation but if we do that the downloaded file is corrupt.

In the https://github.com/swagger-api/swagger-ui/issues/4638 Issue the solution is to upgrade to Swagger UI 3. Is there a workaround in fastify-swagger?

[Stezido]

Isn’t swagger ui same as the dependency "swagger-ui-dist": "3.19.5" or am I missing something ?

You are right fastify-swagger is already using swagger ui 3. This issue is caused by ajv the validator of fastify. For someone who is running in a similar issue i summed up my story.

The Swagger docu describes a “response that returns a file” My response schema looks like this for a gzip-file:

response: {
       200: {
          type : "string",
          format: "binary",
      },
 },

The ajv validator offers following types: number, integer, string, boolean, array, object or null and following formats for type “string”: date, date-time, uri, email, hostname, ipv4, ipv6, regex

So there is a type “string” but no format “binary”!

Only defining the type as “string” or “object” doesn’t make it because the file downloaded will be corrupt

add a byte/binary format to ajv via addFormat would be my guess how to fix it, but I couldn’t add a new format because fast-json-stringify uses it’s own instance of ajv internally. This issue describe a problem of fast-json-stringify I also ran into. The issue was solved in version 1.8.0. of fast-json-stringify by setting the option unknownFormats: “ignore” to the intern ajv instance. So updating fastify made it for me.

[mcollina]

+1, yes.