Project imported pages into the graph#1066
Merged
Merged
Conversation
JeroenDeDauw
force-pushed
the
fix/1022-import-graph-projection
branch
from
July 16, 2026 23:06
6e53d75 to
526fb01
Compare
Fixes #1022 Imported revisions bypass the edit path, so RevisionFromEditComplete never fires for them and their Subjects stayed invisible to queries until RebuildGraphDatabases.php ran. The cause holds for only part of the import surface. Special:Import and the import API already projected, because ImportReporter creates a null revision on top of an import that added revisions, and fires RevisionFromEditComplete for it. importDump.php wraps the importer in no reporter, so nothing projected there. Handling AfterImportPage covers every path at once rather than adding a third special case. It is fired once per page, from WikiImporter itself, once the page's revisions are all in. A revision-insert hook was rejected because imports can add revisions to the middle of a page's history, so it would project non-current revisions. The handler reuses SubjectPageRebuilder, which RebuildGraphDatabases.php (the documented workaround) already uses to project the current revision of a title. It gets the isolating graph plugin, so a projection failure cannot abort the import, and reads the page from the primary database, since a replica can be missing the page or still carry the revision the import replaced. Core's own finishImportPage reads the primary for the same reason. On Special:Import the null revision now reprojects content this hook already projected. That is redundant rather than harmful: both writes carry the same slots and savePage merges, so the outcome is unchanged. Verified on a dev wiki: a page exported with dumpBackup.php and imported under a new title via importDump.php now reaches Neo4j with its Subject, where before it had no node at all. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JeroenDeDauw
force-pushed
the
fix/1022-import-graph-projection
branch
from
July 16, 2026 23:25
526fb01 to
1fa3abf
Compare
JeroenDeDauw
marked this pull request as ready for review
July 16, 2026 23:32
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1022
Imported revisions bypass the edit path, so RevisionFromEditComplete never fires for
them and their Subjects stayed invisible to queries until RebuildGraphDatabases.php ran.
The cause holds for only part of the import surface. Special:Import and the import API
already projected, because ImportReporter creates a null revision on top of an import
that added revisions, and fires RevisionFromEditComplete for it. importDump.php wraps
the importer in no reporter, so nothing projected there.
Handling AfterImportPage covers every path at once rather than adding a third special
case. It is fired once per page, from WikiImporter itself, once the page's revisions are
all in. A revision-insert hook was rejected because imports can add revisions to the
middle of a page's history, so it would project non-current revisions.
The handler reuses SubjectPageRebuilder, which RebuildGraphDatabases.php (the documented
workaround) already uses to project the current revision of a title. It gets the isolating
graph plugin, so a projection failure cannot abort the import, and reads the page from the
primary database, since a replica can be missing the page or still carry the revision the
import replaced. Core's own finishImportPage reads the primary for the same reason.
On Special:Import the null revision now reprojects content this hook already projected.
That is redundant rather than harmful: both writes carry the same slots and savePage
merges, so the outcome is unchanged.
Verified on a dev wiki: a page exported with dumpBackup.php and imported under a new title
via importDump.php now reaches Neo4j with its Subject, where before it had no node at all.