TypeError: Invalid URL on GitHub repo file count badge

[sentry-io]

Sentry Issue: SHIELDS-6Q

TypeError: Invalid URL: /repos/viralvaghela/HacktoberFest_2021/contents/
  File "/app/core/base-service/node-fetch.js", line 24, in request2NodeFetch
    const nodeFetchUrl = new URL(url)
  File "/app/core/base-service/node-fetch.js", line 79, in AsyncFunction.sendRequest
    const { url: nodeFetchUrl, options: nodeFetchOptions } = request2NodeFetch({
  File "/app/core/base-service/base.js", line 230, in GithubDirectoryFileCount._request
    const { res, buffer } = await this._requestFetcher(url, options)
  File "/app/core/base-service/base-json.js", line 45, in GithubDirectoryFileCount._requestJson
    const { buffer } = await this._request({
  File "/app/services/github/github-directory-file-count.service.js", line 121, in GithubDirectoryFileCount.fetch
    return this._requestJson({
...
(5 additional frame(s) were not displayed)

[chris48s]

Example https://img.shields.io/github/directory-file-count/badges/shields

Having deployed #6914 and kept an eye on it for a bit, the only thing that seems to have unexpected broken so far is the GitHub repo file count badge. This is really odd because none of the github badges should be using node-fetch at all. They should all still be using request:

shields/services/github/github-auth-service.js

Lines 5 to 14 in b209f5c

	function createRequestFetcher(context, config) {
	const { sendAndCacheRequestWithCallbacks, githubApiProvider } = context
	return async (url, options) =>
	githubApiProvider.requestAsPromise(
	sendAndCacheRequestWithCallbacks,
	url,
	options
	)
	}

shields/core/base-service/base.js

Line 448 in b209f5c

sendAndCacheRequestWithCallbacks: request,

Also I can't reproduce this failure locally. Its only happening in production. I guess somehow we're registering that one service with sendAndCacheRequest rather than sendAndCacheRequestWithCallbacks in prod but not dev. I can't see how though 🤔

[calebcartwright]

I feel like something funky has been going on with this badge for a while, and whatever we're seeing here probably bears some relation to the behavior we observed in #5967

[chris48s]

I'd forgotten about that issue - well remembered.
Still no closer to knowing what's going on though 😕