Shields: Packagist internal error: Can't generate a version color for undefined

[paulmelnikow]

https://sentry.io/organizations/shields/issues/1109294293/?referrer=github_plugin

Error: Error: Can't generate a version color for undefined
  File "/home/m/shields/core/server/log.js", line 40, in Function.error
    Raven.captureException(msg, sendErr => {
  File "/home/m/shields/core/base-service/base.js", line 298, in PackagistVersion._handleError
    log.error(error)
  File "/home/m/shields/core/base-service/base.js", line 386, in Function.invoke
    serviceData = serviceInstance._handleError(serviceError)
...
(1 additional frame(s) were not displayed)

Error: Error: Can't generate a version color for undefined

[paulmelnikow]

This is generating an "internal error" badge. The stack trace is obscure and I'm not sure exactly why that is. On Sentry, the additional stack frame looks like this:

There's also this error:

As of now, this has occurred 844 times in the last two days.

[paulmelnikow]

This is probably the same error as #3684.

Possible root cause (https://github.com/badges/shields/issues/3684#issuecomment-510320138)

One possible bug from reading the code: what happens if you call latest([])? I'm not sure the schema forbids an empty versions object.

[PyvesB]

I'm not sure the schema forbids an empty versions object.

We may still end up with an empty versions list even though the Joi schema forbids it. Indeed, there is a filter in the PackagistVersion implementation:
versions.filter(version => !/^dev-/.test(version))

The filter is probably still relevant, it was introduced many years ago following this discussion. If my understanding is correct, they aren't actually released versions, they just correspond to branches on a repository, hence the "dev" prefix.

I think a potential fix here is to check if any versions are left in the list before rendering the badge, and if not display something along the lines of no released version found to the user instead.

I'll submit a PR for this. Given that we don't have much information on what caused the root problem, there's no guarantee it will fix all the errors, however it still seems like a sensible check to do anyway.

[PyvesB]

@paulmelnikow are there still any errors reported on Sentry about this?

[paulmelnikow]

I can't tell. Something really strange is going on with Sentry.

When I click on that error, I'm seeing the same stack trace (unsurprising) but a totally different message, "Error: Token pool is exhausted."

It seems like Sentry has started mixing all our errors together.

Some ideas on fixes:

• Migrating to the newer Sentry SDK (#3708)
• Dropping use of domain
• Upgrading to Node 12

[PyvesB]

@paulmelnikow that's annoying. I've started by reviewing the linked PR. 😉

[paulmelnikow]

I guess this is only affecting the Shields internal errors that bubble through our own error handling. These are the ones we started monitoring just recently, in #3706.

[paulmelnikow]

3762 didn't seem to have an effect on this issue, however I did figure out how to see individual events (i.e. a single time the error happened). Here I can see the message that corresponds to each, though still not the full stack trace.

So, I can confirm this particular Packagist error is gone, though I'm getting a new one.

[PyvesB]

Okay, feel free to open another issue when you've got more info about this other error!

[paulmelnikow]

Thought I had, but I guess I didn't click the button! #3767