change errorMessages to handle error message of restful api

[unbyte]

restful apis usually return response of 40x with a body explaining the error reason, and sometimes these error response even can be what we want to get in a 20x response.
and in Shields, all these 40x responses are treated as unusable exceptions and in foo.service.js it's hard to handle these responses.

For example to solve #4811 , I plan to get the SHA of the file and get the size through git/blobs/:sha endpoint (it supports blobs up to 100 megabytes in size). However, I find that the response code from contents/ endpoint of those files larger than 1MB are 403 so they can't be handled in github-size.service.js.

Why not change errorMessages from {[prop: number]: string} to {[prop: number]: (body: string) => string} so many error message can be better handled ?

[chris48s]

Hello.
There's a couple of things tied together here.

Why not change errorMessages from {[prop: number]: string} to {[prop: number]: (body: string) => string} so many error message can be better handled ?

This suggested approach isn't necessarily wrong, but we've implemented over 300 integrations with the current setup and I think this is the first time this has come up. Its certainly an exceptional case. I'd say if there is a case where we absolutely need to do this, I'd probably implement a custom fetch method for that one badge which does this rather than change the signature in core and have to update every badge to account for it.

That said, the specific reason why you're actually requesting this change is..

For example to solve #4811 , I plan to get the SHA of the file and get the size through git/blobs/:sha endpoint

I can't remember if we had it at the time I posted #4811 (comment) , but we certainly now have a GithubAuthV4Service base class which allows us to implement github badges calling the GitHub V4 Graphql API. Changing this badge to a V4 badge would allow us to fix this using a much more efficient call than the V3 blob endpoint (and also wouldn't require this feature).

For example, this badge call

https://img.shields.io/github/size/komandos84/wot_sounds/JakWWII_crew_sounds/zip/JakWW2.zip

fails with the V3 contents API

https://api.github.com/repos/komandos84/wot_sounds/contents/JakWWII_crew_sounds/zip/JakWW2.zip?ref=HEAD

but running the query

{
  repository(owner: "komandos84", name: "wot_sounds") {
    object(expression: "HEAD:JakWWII_crew_sounds/zip/JakWW2.zip") {
      ... on Blob {
        byteSize
      }
    }
  }
}

on the V4 API returns:

{
  "data": {
    "repository": {
      "object": {
        "byteSize": 4936691
      }
    }
  }
}

Would you be interested in submitting a PR taking that approach forward? There are a number of existing Github badges that use the V4 API which you could crib from e.g:

• https://github.com/badges/shields/blob/a66e4f9e10c6ac9cea4dc1597cb44d01089b279a/services/github/github-forks.service.js
• https://github.com/badges/shields/blob/478d14300c4203a134ddf8cbaf5bc1ee8150e5a3/services/github/github-deployments.service.js
• https://github.com/badges/shields/blob/478d14300c4203a134ddf8cbaf5bc1ee8150e5a3/services/github/github-tag.service.js

[unbyte]

I‘d like to try it when I'm free. Really appreciate your reply.