API endpoint /deploys/{deploy_id}/files/{path} randomly gives strange results

Support
1

I’m getting strange results from API endpoint /deploys/{deploy_id}/files/{path} when I deploy a new file. The issue occurs randomly and I have not found any particular pattern. I am currently seeing this issue on site name: eager-einstein-2aea9b.netlify.app, but it is not restricted to this site.

I am programmatically deploying files over this endpoint using the js-client, so a typical call looks like:

    const result = await api.uploadDeployFile({
      deployId,
      path: path,
      body: bufferStream,
    })

In case everything works as expected, I get the following result:

[
  {
    id: '/static/2dbe958e293a5bfe4e082ba42c55086176d3830d/photo-1597321764372-3c0162f1fb8f.jpg',
    path: '/static/2dbe958e293a5bfe4e082ba42c55086176d3830d/photo-1597321764372-3c0162f1fb8f.jpg',
    sha: '2dbe958e293a5bfe4e082ba42c55086176d3830d',
    mime_type: 'image/jpeg',
    size: 91693,
    site_id: 'e3e9fb6b-14cc-48c7-9f24-fdafda8c9b7e',
    deploy_id: '5f539fc098946635d9b6e1cb'
  }
]

However, sometimes I get the following result instead, which is completely out of spec:

[
  {
    ID: '/static/2555efdf6712bc438581a141651552c2eb423ab6/photo-1598454242110-0744560ec77e.jpg',
    Path: '/static/2555efdf6712bc438581a141651552c2eb423ab6/photo-1598454242110-0744560ec77e.jpg',
    SHA: '2555efdf6712bc438581a141651552c2eb423ab6',
    MimeType: 'image/jpeg',
    Size: 170443
  }
]

Note that the ‘deploy_id’ is missing and that the variable names are capitalized. I do not get an error (no promise is thrown) which makes exception handling difficult.

Could you please investigate what is going on here as it currently inhibits proper deployments? Thanks!

3

Hey @styxlab,
The second result you included is the response you get when you successfully PUT a file to the deploy (though I’m not sure why the keys are capitalized!):

The first result you included is the response when you GET the files associated with a deploy, so a URL like this: https://api.netlify.com/api/v1/deploys/:deploy_id/files

Let us know if that helps clarify what you’re seeing or if we can answer other questions!

4

Thanks @jen for getting back. Actually, I’m not able to reproduce the first response, so your explanation with the different GET/PUT requests may fit.

However, the capitalization problem is still present. I’ve tried to isolate the issue and made a simple test example, so you can verify the issue on your end:

Just execute node netlifyAPI.js and observe the following result:

Why are all fields capitalized?
[
  {
    ID: '/static/e3f22d4b3de1c5fb0dc5ab57ff392049e03c872e/now.txt',
    Path: '/static/e3f22d4b3de1c5fb0dc5ab57ff392049e03c872e/now.txt',
    SHA: '1564b09b95255aee96b11cc37a18c8f199632e65',
    MimeType: 'text/plain; charset=utf-8',
    Size: 24
  }
]

Note that you need to put the deploy key in an .env file. I have not published it here.

Thanks a lot for looking into this issue!

5

Hey @styxlab,
This is happening because you make the call in Javascript but our server returns the response in Go, where capitalizing keys is standard. It shouldn’t impact your deploys :slight_smile: are you seeing something different?

8

Yes, deploys are working as expected now (my originial code was not able to cope with capitalized responses - this has been fixed on my end now!).

However, the response does not conform with the API spec:

Therefore I consider this to be bug that should be corrected.

Also note that other endpoints give expected results (not capitalized) so there must be more to it than Go responses fetched from a JS-client.

To prove that the issue is also present when directly calling the endpoint, I have added a direct fetch method to the above example:

I hope this can be corrected.

9

I filed a bug for the discrepancy here: Successful PUT to /deploys/{deploy_id}/files/{path} returns capitalized keys · Issue #256 · netlify/open-api · GitHub Please feel free to follow along and/or chime in if you feel I left anything out, and we’ll update you here if there’s movement on the issue.

1 Like
10

Just wanted to close the loop on this thread - we did get a fix pushed. Thanks again for bringing it to our attention, @styxlab!

1 Like