Error: Failed to get latest version (HTTP code 403).

[slarti-b]

Bug Report

The update command (wp cli check-update) fails with

Error: Failed to get latest version (HTTP code 403).

# wp cli check-update --allow-root
Error: Failed to get latest version (HTTP code 403).

Describe how other contributors can replicate this bug

• Log in to a server which has wp-cli installed (I am logging in as root on a CentOS 7 Linux machine)
• Run wp cli check-update --allow-root

Describe what you expect as the correct outcome

I expect it either to update or report that it is already at latest

Let us know what environment you are running this on
CentOS 7

OS:     Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php
PHP version:    8.1.17
php.ini used:   /etc/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 15.1 Distrib 10.5.19-MariaDB, for Linux (x86_64) using readline 5.1
SQL modes:      STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       /root
WP-CLI packages dir:
WP-CLI cache dir:       /root/.wp-cli/cache
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.7.1

Provide a possible solution

Seems to have happened before - see #3853 - so guessing solution is similar. I first commented there, then noticed last post was a year ago and it was closed so opened a new one

[slarti-b]

I tried the command again about 5 minutes ago and it worked. And then tried again now and it failed again... All from the same machine

[slarti-b]

Hmm... Tried again (running the command manually). Three servers that were failing earlier still failing (one started working briefly then stopped again) but two other servers (in another hosting) plus my dev server are OK. Is it possible we've been blocked for some reason? We don't do it that often - once per delivery per machine and we don't have that many internal machines (this is where it fails) although I guess they all seem to come from the same address.

Is it just an ordinary HTTPS call? Need to check my firewalls

[danielbachhuber]

@slarti-b My guess is that you're hitting GitHub's API rate limit. I believe they're based on IP address, so maybe there's some user code that's hitting the GitHub API too and using all of your requests.

We do allow passing GITHUB_TOKEN in the request:

wp-cli/php/commands/src/CLI_Command.php

Lines 407 to 410 in a71167e

	$github_token = getenv( 'GITHUB_TOKEN' );
	if ( false !== $github_token ) {
	$headers['Authorization'] = 'token ' . $github_token;
	}

When you see this error next, can you generate and pass a GITHUB_TOKEN, and see if that resolves it?

[slarti-b]

Thanks. Has the rate limit changed recently? This is a scripted deploy (we use ansible, so the deploy is the full machine config, and it always installs wp-cli and checks it's up-to-date). This has been running for some years (the wp-cli part certainly hasn't changed for a long time). And then yesterday this started. This morning I tried when i got in and had the same problem. Setting a token does make it work. So, follow-u questions

1. What (approx) is the rate limit?
2. Is there any more docs on the tokens - like what scopes does it need for what wp-cli does? I added probably way more scopes that I really needed, just to test
3. Does the token bypass the rate-limiting, or just put it into another pool. I.e. if my servers are making too many requests, and I use the same token for all of them, will i just hit the limit again or should that solve it?

[danielbachhuber]

Has the rate limit changed recently?

@slarti-b I have no idea

What (approx) is the rate limit?

See https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting

Is there any more docs on the tokens - like what scopes does it need for what wp-cli does? I added probably way more scopes that I really needed, just to test

I think it just needs a basic "Read" scope. It's primarily used to indicate that the request is from an authenticated user.

Does the token bypass the rate-limiting, or just put it into another pool. I.e. if my servers are making too many requests, and I use the same token for all of them, will i just hit the limit again or should that solve it?

See the GitHub docs.

[slarti-b]

OK. Thanks. Will use the token.
For info, current (check their docs for updates) rate limits are

User access token requests are limited to 5,000 requests per hour and per authenticated user. All requests from OAuth applications authorized by a user or a personal access token owned by the user, and requests authenticated with any of the user's authentication credentials, share the same quota of 5,000 requests per hour for that user.

and

For unauthenticated requests, the rate limit allows for up to 60 requests per hour.

One thing, though, is that I don't see any mention of the GITHUB_TOKEN option in the docs (would expect it here and here at least - are there any other commands that make github calls?) Should I log a separate issue somewhere else for the documentation, or leave this open?

[danielbachhuber]

For info, current (check their docs for updates) rate limits are

@slarti-b Thanks for capturing that here!

One thing, though, is that I don't see any mention of the GITHUB_TOKEN option in the docs (would expect it here and here at least - are there any other commands that make github calls?) Should I log a separate issue somewhere else for the documentation, or leave this open?

It would be great to include some mention in the docs for those commands. The docs are automatically generated from the codebase on each release.

Want to submit a pull request with your suggested text?

wp-cli/php/commands/src/CLI_Command.php

Lines 246 to 259 in a71167e

	/**
	* Updates WP-CLI to the latest release.
	*
	* Default behavior is to check the releases API for the newest stable
	* version, and prompt if one is available.
	*
	* Use `--stable` to install or reinstall the latest stable version.
	*
	* Use `--nightly` to install the latest built version of the master branch.
	* While not recommended for production, nightly contains the latest and
	* greatest, and should be stable enough for development and staging
	* environments.
	*
	* Only works for the Phar installation mechanism.

wp-cli/php/commands/src/CLI_Command.php

Lines 180 to 184 in a71167e

	/**
	* Checks to see if there is a newer version of WP-CLI available.
	*
	* Queries the Github releases API. Returns available versions if there are
	* updates available, or success message if using the latest release.

We could also include a more helpful error message when we detect that the failure is related to rate limiting:

wp-cli/php/commands/src/CLI_Command.php

Lines 412 to 416 in a71167e

	$response = Utils\http_request( 'GET', $url, null, $headers, $options );
	if ( ! $response->success || 200 !== $response->status_code ) {
	WP_CLI::error( sprintf( 'Failed to get latest version (HTTP code %d).', $response->status_code ) );
	}