Page MenuHomePhabricator

Special:Import error: "Import failed: Could not open import file"
Open, LowPublic

Description

Author: fran

Description:
Trying to transwiki the page [[Help:ParserFunctions]] and its history on Meta to MediaWiki.org using Special:Import, I ran into an error - it fails with the cryptic message "Import failed: Could not open import file". I have transwiki'd other pages with full histories from Meta to MW.org with no problems, but this page refuses to do so.

Notably, the transfer works if I choose to only copy over the current revision; this is of little use, though, since the GFDL requires that they all be transferred over. This is a rather large stumbling block in the process of moving all MediaWiki documentation from Meta to MediaWiki.org - is there any way to work around or fix this error?


Version: unspecified
Severity: normal

Details

Reference
bz15000
Related Gerrit Patches:
mediawiki/core : masterAdded $wgHTTPImportTimeout setting

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:13 PM
bzimport set Reference to bz15000.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Aug 1 2008, 7:39 AM

Mass compoment change: <some> -> Export/Import

lambdav wrote:

We have the same problem on the French Wikibooks to import from the Wikipédia.
Example : import the page [[w:fr:Résolution d'un sudoku]] always fail returning the following error message :
Échec de l’import : Impossible d’ouvrir le fichier à importer

The page exists. When we try to import a page which doesn't exists the message is :
Échec de l’import : Aucune page à importer.

With some pages, it may success after many number of tries (about 10 attemps), but with some other pages, it never success.

See also [https://bugzilla.wikimedia.org/show_bug.cgi?id=13807 Bug 13807]

I tried that a while back, I think it is just too big.

mike.lifeguard+bugs wrote:

*** Bug 12231 has been marked as a duplicate of this bug. ***

mike.lifeguard+bugs wrote:

*** Bug 13807 has been marked as a duplicate of this bug. ***

mike.lifeguard+bugs wrote:

*** Bug 16981 has been marked as a duplicate of this bug. ***

geraki added a comment.Mar 6 2009, 1:30 PM

Same problem in el.wikipedia. The import fails when trying to import pages with a lot of revisions, so in fact the tool is mostly useless (nobody is interested importing stubs).

mike.lifeguard+bugs wrote:

(In reply to comment #7)

Same problem in el.wikipedia. The import fails when trying to import pages with
a lot of revisions, so in fact the tool is mostly useless (nobody is interested
importing stubs).

Worse than that, it actually fails ~90% of the time when trying to import only one revision. There is obviously something going on here which has nothing to do with the difficulty in retrieving page text quickly from external storage for all revisions of a page, since that's not required for importing the top revision. See bug 16875.

IAlex added a comment.Jan 2 2011, 1:35 PM
  • Bug 26493 has been marked as a duplicate of this bug. ***
He7d3r added a comment.May 6 2011, 9:24 PM

Any updates on this?

I've tried to import the page again and I'm still getting the error described on Bug 26493.

Hydriz added a comment.Jun 4 2011, 2:22 PM

*** Bug 21409 has been marked as a duplicate of this bug. ***

Hydriz added a comment.Jun 4 2011, 2:24 PM

*** Bug 17281 has been marked as a duplicate of this bug. ***

john wrote:

Please do not change priority unless you are a developer, and raising the severity to blocker won't help this move.

lambdav wrote:

Why is there no action to resolve this blocking problem ??
Should we stop reporting problems as nothing has been done for this one since 2008 !?

john wrote:

This seems to be a Wikimedia problem, moving to the appropriate product.

(In reply to comment #15)

This seems to be a Wikimedia problem, moving to the appropriate product.

Are you sure? Import/export via special pages is notoriously unreliable on all wikis I've heard of.

TTO added a comment.Sep 21 2013, 9:59 AM

This is mostly caused by timeouts (e.g. try to import [[Wikipedia:Sandbox]] or [[wikt:water]] with all revisions).

The solution here would be to increase $wgHTTPTimeout on the Wikimedia cluster, or to introduce a separate timeout config variable into MediaWiki that will affect imports only.

Adding ops keyword and CC'ing Reedy - they should know whether increasing the timeout is OK, and whether it will actually help to solve this problem.

(In reply to comment #17)

The solution here would be to increase $wgHTTPTimeout on the Wikimedia
cluster,or to introduce a separate timeout config variable into MediaWiki
that will affect imports only.

MediaWiki & Cluster => CC'ing Tim.

fgiunchedi added a subscriber: fgiunchedi.

Not sure this is Operations scope

TTO added a comment.Dec 1 2016, 1:16 AM
In T17000#192142, @TTO wrote:

The solution here would be to increase $wgHTTPTimeout on the Wikimedia cluster, or to introduce a separate timeout config variable into MediaWiki that will affect imports only.
Adding ops keyword and CC'ing Reedy - they should know whether increasing the timeout is OK, and whether it will actually help to solve this problem.

@fgiunchedi: I added Ops to get feedback on the consequences of increasing the value of $wgHTTPTimeout on the production cluster.

TTO added a project: Operations.EditedDec 30 2016, 10:45 AM

Sorry Filippo... I'm adding Ops back per my previous comment. Otherwise this will be stalled forever.

If ops don't answer, I think it's reasonable to proceed by trial and error. The first step would be to set $wgHTTPTimeout at whatever is the current timeout for API requests (at least 60 seconds?).

Joe added a subscriber: Joe.Dec 30 2016, 2:37 PM

If ops don't answer, I think it's reasonable to proceed by trial and error. The first step would be to set $wgHTTPTimeout at whatever is the current timeout for API requests (at least 60 seconds?).

Trial and error is not advisable with important parameters that can cause serious issues if mistuned.

But I have a more fundamental question: why do you all think this issue is originated from the value of $wgHTTPTimeout? I don't see anything specific here pointing to that being the problem.

Getting into the value of the variable: at the moment the timeout for internal HTTP requests is set to 25 seconds (the MediaWiki default); I think it would be advisable to have a separated timeout for this action specifically, and maybe limit multi-page imports to some specific class of users. Any timeout longer than 60 seconds doesn't really make much sense.

I would downvote any patch increasing wgHTTPTimeout globally by more than 100% from its current value anyways.

TTO added a comment.Dec 31 2016, 2:28 AM
In T17000#2907375, @Joe wrote:

But I have a more fundamental question: why do you all think this issue is originated from the value of $wgHTTPTimeout? I don't see anything specific here pointing to that being the problem.

It's not a server timeout: I can download the entire 353 MB XML dump of Wikipedia:Sandbox on enwiki (https://en.wikipedia.org/wiki/Special:Export/Wikipedia:Sandbox?history=1) with no problems. So, by process of elimination, it must be a client timeout.

Indeed if you try to import all revisions of enwiki's Wikipedia:Sandbox using transwiki import onto another WMF wiki, it fails with "Import failed: Could not open import file" after 26 or 27 seconds! Coincidence or...?

I think it would be advisable to have a separated timeout for this action specifically

Seems reasonable.

and maybe limit multi-page imports to some specific class of users.

Imports are already limited to sysops, and they're not exactly common actions anyway.

Any timeout longer than 60 seconds doesn't really make much sense.

I don't see why not; imports can be very long operations by their very nature.

Peachey88 added a subscriber: Peachey88.EditedDec 31 2016, 2:39 AM

Don't we already have maintenance scripts that allow these large export/imports to be done server side?

TTO added a comment.Dec 31 2016, 6:22 AM

Don't we already have maintenance scripts that allow these large export/imports to be done server side?

Technically it could be done server-side, but it would be a bit tedious, and I don't see any benefit to doing it that way. It's still going to take just as long.

Change 330171 had a related patch set uploaded (by Filip):
Added $wgHTTPImportTimeout setting

https://gerrit.wikimedia.org/r/330171

Filip claimed this task.Jan 2 2017, 7:03 PM
Filip added a subscriber: Filip.

@TTO: Added $wgHTTPImportTimeout setting.

Change 330171 merged by jenkins-bot:
Added $wgHTTPImportTimeout setting

https://gerrit.wikimedia.org/r/330171

Filip closed this task as Resolved.Jan 3 2017, 6:59 AM

Patch got merged, so closing as 'resolved'.

Nemo_bis reopened this task as Open.Jan 3 2017, 8:15 AM

Given the default for $wgHTTPImportTimeout is the same 25 seconds, and the setting was not changed on Wikimedia, this is not fixed for Wikimedia-General-or-Unknown.

Aklapper added a subscriber: Aklapper.

The pleasure of having tasks mixing up the general MediaWiki code base and the specific configuration of Wikimedia sites. :(
Should we split of the Wikimedia site request into a separate task? Feels way cleaner.

Joe added a comment.Jan 3 2017, 10:03 AM
In T17000#2908075, @TTO wrote:

Any timeout longer than 60 seconds doesn't really make much sense.

I don't see why not; imports can be very long operations by their very nature.

Because we have such timeouts set both in our API and appserver layer and even shorter timeouts in varnish IIRC; setting a higher timeout will result in the import action maybe working but at the same time the user receiving an error page.

Joe added a comment.Jan 3 2017, 10:03 AM

The pleasure of having tasks mixing up the general MediaWiki code base and the specific configuration of Wikimedia sites. :(
Should we split of the Wikimedia site request into a separate task? Feels way cleaner.

Well the two things were quite entangled, but I think it would be fair to separate the tasks.

As an additional note, it also affects it.wikiversity importing this page (2000 revisions).