Empty redirect when requesting archive through API

A request like this

https://gitlab.com/api/v3/projects/72724/repository/archive?private_token=yourprivatetoken

used to result in the download of a tarball of the files at the HEAD of the default branch (or another specified commit by sha) as specified here. However, since today, making this request results in an empty redirect, with a 302 response code, but no content (and therefore nowhere to redirect to).

As returned by Perl:

HTTP::Response  {
    Parents       HTTP::Message
    ...
    internals: {
        _content    """",
        _headers    HTTP::Headers,
        _msg        "Found",
        _previous   HTTP::Response,
        _protocol   "HTTP/1.1",
        _rc         302,
        _request    HTTP::Request
    }
}

Performing the same query with Firefox results in a The page isn't redirecting properly error being displayed.

Title changed from Incorrect redirect when requesting archive through APi to Empty redirect when requesting archive through API

This problem spreads through to requests done through the GUI as well: clicking on the archive button to download a ZIP version of the repository also results in an endless redirect.

The request in that case is

GET http://gitlab.com/gitlab-org/gitlab-test/repository/archive.zip

(or any other repository of your choice).

Related: #2185 (closed)

/cc @DouweM This may be a regression in 7.13.3. What do you think?

I can't reproduce this with the development tool kit.
I assume that it is an omnibus problem. (Wrong nginx config?)

I'm pretty sure this was working a couple of days ago.

Maybe it's related to the new server that got installed today?

Based on reading the code, I think this is what is happening:

1. User attempts to download a ZIP archive
2. RepositoryArchiveWorker schedules a Sidekiq task to archive the process
3. ArchiveRepositoryService waits for 5 seconds for the archive to be created; if it does not return with a path to the archived file, the RepositoriesController redirects to the original URL.
4. Repeat step 3.
5. User's browser gives up after too many retries.

I suspect the recent increase in the Sidekiq queue is causing delays here. Perhaps there ought to be a Web page that shows a "Please wait" and attempts to retry periodically. This would be better than relying on redirects.

@stanhu scripts and cli tools need to be able to get the archive by its URL. That won't work if it shows a Waiting page with a JS-initiated refresh...

@DouweM Good point. There are two different endpoints here. Both the browser endpoint (/:namespace_id/:project_id/repository/archive(.:format)) and the API endpoint (/v3/api/projects/:id/repository/archive) do the same thing as described above in different places. I was talking about modifying the browser behavior.

There's no guarantee that the archive will complete before timeouts kick in and the client disconnects. A large Sidekiq queue and/or large repository will slow things down.

It seems to me that we may need to introduce a mechanism for scheduling archive builds and retrieving their status/paths when they are finished.

I might be missing something here, but this was working only days ago. Can this not be reverted to whatever setup was working before, so that this feature is available while a better, more future-proof solution (like the one I gather @stanhu is talking about) is being developed?

Right now, the command-line tool that I'm working on is useless because snapshots cannot be downloaded through the API. I bet others are also broken.

@jjatria I believe it was working before because the site was working fast, but over the last few days GitLab.com has been experiencing higher load. Asynchronous tasks like archiving projects has been slower than usual as a result. I believe more hardware is being thrown at the issue:

https://twitter.com/gitlabstatus

@jjatria I just tested with https://gitlab.com/gitlab-org/gitlab-ce, and it seems to be working again, both using the web interface and the API. Could you check if it's working again for you as well? The issue seems to have been caused by high load on gitlab.com these last few days, but that's mostly been resolved now.

Yeah, this is working again now. Good!

How could this be solved so that next time this happens (knock on wood...) users get some sort of notification? A sort of TIMEOUT response or something like that, so users can act accordingly (and wait a bit instead of panic, like I did when I assumed something had broken down).

Status changed to closed

mentioned in merge request !14785