Wikimedia Bugzilla is closed!

Chrome messed up the text of the exception being thrown so I tried to make it trigger again from the console with an identical request:

( new mw.Api ).post( {
    action: 'articlefeedbackv5',
    found: '1',
    comment: 'asd',
    anontoken: 'I1FwW4QHH7nnq0bFCw0zsfXTM9P5Uzzc',
    pageid: '6270',
    revid: '57949',
    bucket: '6',
    cta: '4',
    link: 'X'
} ).fail( function ( code, result ) {
    console.log( result.error.info );
    console.log( result.error['*'] );
} );
Object {abort: function, state: function, always: function, then: function, promise: function…}
Exception Caught: Unable to resolve site ID 'enwiki'!


#0 /data/project/apache/common-local/php-master/extensions/Wikibase/client/includes/LangLinkHandler.php(396): Wikibase\LangLinkHandler->getSiteGroup()
#1 /data/project/apache/common-local/php-master/extensions/Wikibase/client/includes/LangLinkHandler.php(428): Wikibase\LangLinkHandler->getEffectiveRepoLinks(Object(Title), Object(ParserOutput))
#2 /data/project/apache/common-local/php-master/extensions/Wikibase/client/WikibaseClient.hooks.php(370): Wikibase\LangLinkHandler->addLinksFromRepository(Object(Title), Object(ParserOutput))
#3 [internal function]: Wikibase\ClientHooks::onParserAfterParse(Object(Parser), 'asd', Object(StripState))
#4 /data/project/apache/common-local/php-master/includes/Hooks.php(199): call_user_func_array('\Wikibase\Clien...', Array)
#5 /data/project/apache/common-local/php-master/includes/GlobalFunctions.php(3829): Hooks::run('ParserAfterPars...', Array)
#6 /data/project/apache/common-local/php-master/includes/parser/Parser.php(387): wfRunHooks('ParserAfterPars...', Array)
#7 /data/project/apache/common-local/php-master/extensions/SpamBlacklist/SpamBlacklist_body.php(55): Parser->parse('asd', Object(Title), Object(ParserOptions))
#8 /data/project/apache/common-local/php-master/extensions/ArticleFeedbackv5/ArticleFeedbackv5.utils.php(359): SpamBlacklist->filter(Object(Title), 'asd', '')
#9 /data/project/apache/common-local/php-master/extensions/ArticleFeedbackv5/api/ApiArticleFeedbackv5.php(121): ArticleFeedbackv5Utils::validateSpamBlacklist('asd', 6270)
#10 /data/project/apache/common-local/php-master/includes/api/ApiMain.php(840): ApiArticleFeedbackv5->execute()
#11 /data/project/apache/common-local/php-master/includes/api/ApiMain.php(380): ApiMain->executeAction()
#12 /data/project/apache/common-local/php-master/includes/api/ApiMain.php(351): ApiMain->executeActionWithErrorHandling()
#13 /data/project/apache/common-local/php-master/api.php(73): ApiMain->execute()
#14 /data/project/apache/common-local/w/api.php(3): require('/data/project/a...')
#15 {main}

Actually it seems this error is unrelated, sorry. Will have to wait for that error to be resolved before I can look into the original issue again.

Seems to be working now. Maybe that was the issue after all...

Strange, I am still getting "Form submission error"

Created attachment 12746 [details]
response causing AFT error

As if the POST from the AFT is not invoking the API at all.  The response is just the static HTML page of the API documentation.

I managed to post a feedback on http://en.wikipedia.beta.wmflabs.org/wiki/Aftpage

I found out last week that the resource loader url (load.php) was pointing to the text cache ( en.wikipedia.beta.wmflabs.org/w/load.php ) instead of bits ( bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/w/load.php ).  

When resourceloader cache is unvalidated, there is no purge sent to the text cache so we had an old Javascript version being delivered.  That most probably caused the issue reported there.


I have deployed a change on beta a few minutes ago that points load.php to bits.beta.wmflabs.org : https://gerrit.wikimedia.org/r/#/c/70322/ . I guess that solve it.

I am still seeing this behavior consistently along with Bug 50622

As a logged in user I was able to post an update; as an anonymous user, even after page purge, I saw the error Chris mentions.

And now as an anonymous user it is working for me. Can you say if it's consistent for you and if it's both logged in and logged out that you have the problem?

This seems to have miraculously fixed itself.  I looked through the recent merges but didn't see any likely reasons.