project Websites / Gitlab Issue Listing Script avatar

websites/Gitlab-Issue-Listing-Script#58: Wiki Page Links Broken

Issue Information

Issue Type: issue
Status: closed
Reported By: btasker
Assigned To: btasker

Created: 28-Jan-23 10:20

Labels: Bug


I have a mirror of some projects at

Most don't use the Wiki, but there's one where I wanted to start.

However, whilst the Wiki index shows up correctly, the links to the pages themselves are broken.

They contain the original host name (docker-host), having not been replaced by wget for some reason.

Need to look at what's different about these links - that there's a hostname there at all suggests that they might be absolute rather than relative links.

Toggle State Changes


assigned to @btasker

Have had a look, this looks like there was an issue during mirroring - when the pages are requested from the mirror container directly they load fine. I think Gitlab's API might briefly have gone unavailable during mirroring, so wget wasn't able to fetch the pages and therefore didn't convert the links.

The mirror's not caught up overnight.

Although we can see those pages were requested, they failed again

--2023-01-29 09:35:04--  http://docker-host:1580/wiki/project-management-only/scraper-snitch-bot/page/Receipt-File-Information.html
Reusing existing connection to docker-host:1580.
HTTP request sent, awaiting response... 500 Internal Server Error
2023-01-29 09:35:04 ERROR 500: Internal Server Error.

Curiously, we haven't logged anything on the server side. Turning display_errors on and running a capture at the same time to see whether we can collect anything.

Commit views seem to view periodically with 500s too, but there are quite a lot of those to fetch (so might well just be hitting limits).

OK, looks like the network call failed

<br />
<b>Warning</b>:  Redis::connect(): php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution in <b>/var/www/html/lib/gitlab.php</b> on line <b>940</b><br />
<br />
<b>Warning</b>:  Attempt to read property "slug" on null in <b>/var/www/html/lib/gitlab.php</b> on line <b>637</b><br />
<br />
<b>Fatal error</b>:  Uncaught Error: Attempt to assign property &quot;gitlab_url&quot; on null in /var/www/html/lib/gitlab.php:637
Stack trace:
[#0](/issue/websites/Gitlab-Issue-Listing-Script/0.html) /var/www/html/lib/router.php(105): GILSGitlab-&gt;getWikiPage('project-managem...', 'Receipt-File-In...')
[#1](/issue/websites/Gitlab-Issue-Listing-Script/1.html) /var/www/html/index.php(14): GILSRouter-&gt;route('/wiki/project-m...')
[#2](/issue/websites/Gitlab-Issue-Listing-Script/2.html) {main}
  thrown in <b>/var/www/html/lib/gitlab.php</b> on line <b>637</b><br />

We're using a hostname for redis in config, so have replaced that with an IP. Re-running

Obviously we should also fix the code so that it handles that gracefully (or logs the issue somewhere).

OK, so we already are catching redis failures

try {
                $this->redis->connect($config->redis_host, $config->redis_port);

                if ($config->redis_pass){
            catch (exception $e){
                // We failed to connect
                // let's not kill the application
                // The library will push warnings out, so it's not a silent failure
                $this->redis = false;

The "network" issue though, is presumably in docker - the hostname that we're trying to resolve is actually in /etc/hosts.

Whatever the cause though, if we're unable to lookup redis's hostname, we're presumably also unable to use the network to reach gitlab's API, so we get nothing back from there, which we're failing to handle - the codebase largely assumes that we'll get a reply from the API.

To be fair, we correctly fail out with an error when we don't, we just don't log anything to aid troubleshooting.


mentioned in commit d91273730d0e33f35347e95fc8f50129db80354b

Commit: d91273730d0e33f35347e95fc8f50129db80354b 
Author: B Tasker                            
Date: 2023-01-29T10:05:29.000+00:00 


Add error logging for websites/Gitlab-Issue-Listing-Script#58

Make it easier to troubleshoot when/why 500s are being returned.

+7 -1 (8 lines changed)