Bintray badge is flaky

[agemooij]

The Bintray badge seems to be broken; all versions are rendered as a grey "invalid".

Perhaps the API has changed? I've tested with multiple repositories but the example on shields.io itself is also broken:

[migmruiz]

Having the same issue here

[xvik]

It works sometimes, but mostly not. Could it be caused by bintray api limits?

[nwalters512]

Can confirm that this is still an issue. It was working yesterday, but all Bintray badges (at least the one for my project and the example from shields.io) are currently showing "invalid".

[raniejade]

Badge is broken for my project as well. Rate limiting is very likely the culprit.

[espadrine]

The request performed is curl -v 'https://bintray.com/api/v1/packages/asciidoctor/maven/asciidoctorj/versions/_latest'. I cannot find a X-RateLimit-Limit header in the response. Is this issue still ongoing? Did they switch their rate limiting system?

[cdeszaq]

As of today, the issue is still present. Does anyone have contacts at Bintray to see if we can resolve this?

[xvik]

Here is what bintray support answered about this issue:

Thank you for contacting us.
We were not able to reproduce this behaviour using a custom shield.
We also verified that the 'getLatestVersion' API is not rate limited so this does not appear to be the issue.

So there are no limits on bintray side and probably the problem is on the shields side.

Dear shield maintainers, please look actual error messages in your logs and try to investigate this.

P.S. I also asked bintray support to allow bintray badge customization (different message), but don't know if this ever happen:

We have forwarded your request to our Product Team and will consider adding the option to customise the badge.

[Fi5t]

The badge has broken again...

[paulmelnikow]

It looks like the badge has been flaky for a long time.

Unfortunately the server doesn't log all the API calls. So I think the way to resolve this long-standing issue is to set up a recurring test over a week or more, and send documentation of the failures to their support.

If anyone is game, would be great to have your help!

[laughedelic]

Still a problem. From the example on shields.io:

[remmeier]

any update?

[paulmelnikow]

Copying from above: I think the way to resolve this long-standing issue is to set up a recurring test over a week or more, and send documentation of the failures to their support. If anyone is game, would be great to have your help!

[tovbinm]

Just FYI, Bintray seem to have their own badge now. But it would still be nice to have the Shields one.

[enveeed]

It is possible to use the Shields badge via the dynamic endpoint using the URL for the Bintray API and query=name, which seems to work for me when the normal bintray badge displays 'invalid', e.g. using

https://bintray.com/api/v1/packages/asciidoctor/maven/asciidoctorj/versions/_latest

https://img.shields.io/badge/dynamic/json.svg?label=latest&query=name&style=flat-square&url=https%3A%2F%2Fapi.bintray.com%2Fpackages%2Fasciidoctor%2Fmaven%2Fasciidoctorj%2Fversions%2F_latest

---

https://img.shields.io/badge/dynamic/

https://img.shields.io/bintray/

[Andre601]

I can confirm that this issue still exists.

[calebcartwright]

Interestingly enough, it seems that the API call we use does not require any authentication for public packages:

https://bintray.com/docs/api/#_get_version
https://bintray.com/api/v1/packages/asciidoctor/maven/asciidoctorj/versions/_latest

And when I remove auth in our call, the badges work just fine

shields/services/bintray/bintray.service.js

Lines 47 to 54 in 7a7bf66

	async fetch({ subject, repo, packageName }) {
	// https://bintray.com/docs/api/#_get_version
	return this._requestJson({
	schema,
	url: `https://bintray.com/api/v1/packages/${subject}/${repo}/${packageName}/versions/_latest`,
	options: { auth: this.authHelper.basicAuth },
	})
	}

[calebcartwright]

False alarm (some fluke in my local env). However, it does seem that the bintray badges are working fine in other environments, like staging:

https://shields-staging.herokuapp.com/bintray/v/asciidoctor/maven/asciidoctorj

So my guess is that in production we're either:

1. Configured with bintray auth which is then being unnecssarily included in the requests to the bintray APIs (and AFAICT when tokens are used they are rate limited, even if the token is not needed, https://bintray.com/docs/api/#_authentication)
2. Requests from the badge servers to the bintray API are being throttled/blocked

[calebcartwright]

@paulmelnikow - do you know if we have bintray_user and/or bintray_apikey set on the prod badge servers?

[paulmelnikow]

Yes, they are both set. I think the auth was added not for private projects, but because it provided a higher rate limit.

We could try creating a second token and an auth pool for Bintray… though maybe they could give us a megatoken instead? Has anyone managed to reach them?

[calebcartwright]

I'm thinking we may be able to solve this by unsetting bintray_user and bintray_apikey on the badge servers.

Support for bintray goes way back in Shields' history, so apologies if I've missed any relevant threads or discussion.

From what I can tell, when bintray support was first added, the bintray API we use to get the latest version required authentication (like the Wheelmap and SymfonyInsight services do)
#58
#517

As such, our calls were subject to the rate limits imposed by JFrog

The current limit per non-Premium user is 300 queries a day, and 1440 per month. Limits are returned in the X-RateLimit headers.

However, at some point over the years, JFrog made the bintry API available anonymously and non-rate limited for public packages (private packages still require auth), which would explain the response from the JFrog Support team that was shared above

https://bintray.com/docs/api/#_get_version

Security: Authenticated user with 'read' permission for private repositories, or version read entitlement.

For example:
https://bintray.com/api/v1/packages/asciidoctor/maven/asciidoctorj/versions/_latest

{ 
  "name":"2.1.0",
  "desc":null,
  "package":"asciidoctorj",
  "repo":"maven",
  "owner":"asciidoctor",
  "labels":[ 
    "asciidoctor",
    "java",
    "asciidoctorj",
    "asciidoc",
    "jruby"
  ],
  "published":true,
  "attribute_names":[ 

  ],
  "created":"2019-06-22T16:33:07.367Z",
  "updated":"2019-06-22T16:48:02.333Z",
  "released":"",
  "ordinal":36.0,
  "rating_count":0
}

Since we've got bintray auth configured on the badge servers, we're (IMO) unnecessarily authenticating and subjecting our calls to rate limiting which is resulting in the flaky badge behavior we are seeing.

There is another issue (#1193) requesting bintray download count badges, and the bintray APIs needed for download stats will require auth, but I think we can tackle the auth/rate limiting over there.

[paulmelnikow]

Okay, I'm game to remove the credentials on the next deploy and see how it goes!

[calebcartwright]

🤞

[calebcartwright]

Were the creds removed on the last deploy? If so I'll try to keep checking on the badges to see if we get any more invalid's

[paulmelnikow]

Yes, they were. I'm rolling back the code now, but the creds will remain unset.

[calebcartwright]

AFAICT the bintray badges have been consistently working since we removed the creds. Has anyone seen anymore invalid badges in the last 4 days?

[calebcartwright]

It's been over a week since the change was made and it appears this has been resolved. I'm going to close this issue out accordingly

[mpetuska]

Could potentially be replaced with https://bintray.com/api/ui/package/:subject/:repo/:package which returns a lot of info including {..., "latestVersion": "x.y.z-M..."}