ApiUsageException when running rebuildData.php on a closed wiki

[krabina]

This happens on pages where the #knowledgegraph parser function is active when running rebuildData.php on a wiki where $wgGroupPermissions['*']['read'] = false; is set. Workaround is to set $wgGroupPermissions['*']['read'] = true; then rebuildData.php finishes.

MediaWiki\Api\ApiUsageException from line 84 of includes/api/ApiUsageException.php: You need read permission to use this module.
#0 includes/api/ApiBase.php(1578): MediaWiki\Api\ApiUsageException::newWithMessage()
#1 includes/api/ApiMain.php(1778): MediaWiki\Api\ApiBase->dieWithError()
#2 includes/api/ApiMain.php(1960): MediaWiki\Api\ApiMain->checkExecutePermissions()
#3 includes/api/ApiMain.php(911): MediaWiki\Api\ApiMain->executeAction()
#4 extensions/KnowledgeGraph/includes/KnowledgeGraph.php(778): MediaWiki\Api\ApiMain->execute()
#5 extensions/KnowledgeGraph/includes/KnowledgeGraph.php(344): KnowledgeGraph::setSemanticDataFromApi()
#6 includes/parser/Parser.php(3429): KnowledgeGraph::parserFunctionKnowledgeGraph()
#7 includes/parser/Parser.php(3110): MediaWiki\Parser\Parser->callParserFunction()
#8 includes/parser/PPFrame_Hash.php(280): MediaWiki\Parser\Parser->braceSubstitution()
#9 includes/parser/Parser.php(3303): MediaWiki\Parser\PPFrame_Hash->expand()
#10 includes/parser/PPFrame_Hash.php(280): MediaWiki\Parser\Parser->braceSubstitution()
#11 includes/parser/Parser.php(2944): MediaWiki\Parser\PPFrame_Hash->expand()
#12 includes/parser/Parser.php(1592): MediaWiki\Parser\Parser->replaceVariables()
#13 includes/parser/Parser.php(694): MediaWiki\Parser\Parser->internalParse()
#14 includes/content/WikitextContentHandler.php(384): MediaWiki\Parser\Parser->parse()
#15 includes/content/ContentHandler.php(1743): MediaWiki\Content\WikitextContentHandler->fillParserOutput()
#16 includes/content/Renderer/ContentRenderer.php(79): MediaWiki\Content\ContentHandler->getParserOutput()
#17 extensions/SemanticMediaWiki/includes/ContentParser.php(170): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput()
#18 extensions/SemanticMediaWiki/includes/ContentParser.php(129): SMW\ContentParser->fetchFromContent()
#19 extensions/SemanticMediaWiki/src/MediaWiki/Jobs/UpdateJob.php(193): SMW\ContentParser->parse()
#20 extensions/SemanticMediaWiki/src/MediaWiki/Jobs/UpdateJob.php(136): SMW\MediaWiki\Jobs\UpdateJob->parse_content()
#21 extensions/SemanticMediaWiki/src/MediaWiki/Jobs/UpdateJob.php(93): SMW\MediaWiki\Jobs\UpdateJob->doUpdate()
#22 extensions/SemanticMediaWiki/src/SQLStore/Rebuilder/Rebuilder.php(242): SMW\MediaWiki\Jobs\UpdateJob->run()
#23 extensions/SemanticMediaWiki/src/Maintenance/DataRebuilder.php(464): SMW\SQLStore\Rebuilder\Rebuilder->rebuild()
#24 extensions/SemanticMediaWiki/src/Maintenance/DataRebuilder.php(382): SMW\Maintenance\DataRebuilder->doUpdateById()
#25 extensions/SemanticMediaWiki/src/Maintenance/DataRebuilder.php(223): SMW\Maintenance\DataRebuilder->rebuildAll()
#26 extensions/SemanticMediaWiki/maintenance/rebuildData.php(200): SMW\Maintenance\DataRebuilder->rebuild()
#27 maintenance/includes/MaintenanceRunner.php(703): SMW\Maintenance\rebuildData->execute()
#28 maintenance/doMaintenance.php(100): MediaWiki\Maintenance\MaintenanceRunner->run()
#29 extensions/SemanticMediaWiki/maintenance/rebuildData.php(294): require_once('...')
#30 {main}

[gesinn-it-gea]

Confirmed reproducible against a local MW 1.43 + SMW 7.2.0 setup (make install in this repo).

Steps:

1. Create a page whose wikitext actually populates nodes= for the parser function, e.g.:

   [[HasFriend::TargetPage]]
   {{#knowledgegraph: nodes=KGTestPage |depth=2 }}
   

   (Note: setSemanticDataFromApi() is only reached when nodes resolves to a known title — a page-referencing-itself is enough to trigger it.)
2. Close the wiki: $wgGroupPermissions['*']['read'] = false;
3. Run php extensions/SemanticMediaWiki/maintenance/rebuildData.php --page=KGTestPage --force-update -v

Result: Same exception and call chain as reported:

MediaWiki\Api\ApiUsageException from line 84 of includes/api/ApiUsageException.php: You need read permission to use this module.
...
#4 extensions/KnowledgeGraph/includes/KnowledgeGraph.php(684): MediaWiki\Api\ApiMain->execute()
#5 extensions/KnowledgeGraph/includes/KnowledgeGraph.php(285): KnowledgeGraph::setSemanticDataFromApi(...)
...
#17 extensions/SemanticMediaWiki/src/MediaWiki/Jobs/UpdateJob.php(222): SMW\Parser\ContentParser->fetchFromContent()
...

Also confirmed the workaround: with $wgGroupPermissions['*']['read'] = true; the same rebuild completes without error.

Root cause: KnowledgeGraph::setSemanticDataFromApi() and KnowledgeGraph::getAllPropertiesForNode() both build an internal smwbrowse API call via new \ApiMain($request) without overriding the request's user context. Under a CLI maintenance script (rebuildData.php, edit.php, ...), the ambient user is anonymous. On a closed wiki ($wgGroupPermissions['*']['read'] = false), that anonymous user has no read right, so ApiMain::checkExecutePermissions() throws ApiUsageException and aborts the whole parse/rebuild.

A fix would need to give the internal ApiMain request a context user that's allowed to read (e.g. a system user), rather than inheriting whatever the ambient global user is.

[gesinn-it-gea]

Investigated whether existing test-coverage issues would have caught this

No open issue targets the permission/CLI-context aspect directly, but two open test-coverage issues target the exact code paths involved and are worth linking here:

• test: tests for the main path of KnowledgeGraph::setSemanticDataFromApi() #71 — "test: tests for the main path of KnowledgeGraph::setSemanticDataFromApi()" — targets exactly the method whose ApiMain::execute() call throws here. Its listed scenarios (property filtering, recursion, file namespace, categories, property metadata, the generic $result['error'] case) don't include "caller has no read permission" (which surfaces as an uncaught ApiUsageException, not a $result['error'] array).
• test: tests for KnowledgeGraph::getAllPropertiesForNode() #73 — "test: tests for KnowledgeGraph::getAllPropertiesForNode()" — the second call site with the same new \ApiMain($request) pattern; same gap.

More importantly, the tests already merged for the sibling API endpoints (KnowledgeGraphApiLoadNodesExecuteTest, KnowledgeGraphApiLoadPropertiesExecuteTest, KnowledgeGraphApiLoadCategoriesExecuteTest, and KnowledgeGraphParserFunctionKnowledgeGraphTest) all extend ApiTestCase/MediaWikiIntegrationTestCase and exercise the internal smwbrowse request via doApiRequestWithToken(), which authenticates as a privileged test user. That means the internal ApiMain call in these tests always runs with read permission — the failure mode from this issue (an anonymous/unprivileged ambient user, as is the case under rebuildData.php) can't surface with that test pattern even if #71/#73 are implemented, unless they specifically add a case with $wgGroupPermissions['*']['read'] = false (or an anonymous user lacking read).

Suggest adding that scenario explicitly to #71/#73, or tracking it as its own regression test alongside whatever fix lands here.