GraphQL rate limit errors don't always get retried.

[jyasskin]

I ran a GH Action that exceeds its primary rate limit, and the first time (https://github.com/jyasskin/spec-maintenance/actions/runs/6581598228/job/17881791340#check-step-7) plugin-throttling called my onRateLimit function and retried accordingly, and the second time (https://github.com/jyasskin/spec-maintenance/actions/runs/6581598228/job/17920483150) (on the same commit), it didn't.

It looks like the ones that skip onRateLimit have a 200 response code, while earlier runs that weren't using plugin-throttling showed a 403 response code for secondary rate limits. (They didn't get far enough to exceed the primary rate limit, so I don't have their response code for that.) Could Bottleneck only be firing the failed event on HTTP-level failures, and so

plugin-throttling.js/src/wrap-request.ts

Lines 44 to 54 in c4147c9

	if (
	res.data.errors != null &&
	// @ts-expect-error
	res.data.errors.some((error) => error.type === "RATE_LIMITED")
	) {
	const error = Object.assign(new Error("GraphQL Rate Limit Exceeded"), {
	response: res,
	data: res.data,
	});
	throw error;

should be calling onRateLimit itself?

[jyasskin]

It's not that it was a 200 response code, since https://github.com/jyasskin/spec-maintenance/actions/runs/6618851077/job/17978147853 exceeded the primary rate limit, did go through my onRateLimit handler, and was also a 200 response code.

[jyasskin]

Aha!

plugin-throttling.js/src/index.ts

Line 141 in 60cec56

error.response.headers["x-ratelimit-remaining"] === "0"

checks for x-ratelimit-remaining === 0, but GraphQL queries with a cost >1 can exceed the rate limit even if the amount remaining is >0. And this does distinguish the cases where onRateLimit is correctly called.

[github-actions]

🎉 This issue has been resolved in version 8.1.2 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀