Page MenuHomeMiraheze

Cargo Exception (need exception details please)
Closed, InvalidPublic

Assigned To
None
Authored By
CrystalClear
Feb 24 2022, 19:23
Referenced Files
F1731409: Image 072.jpg
Mar 18 2022, 05:23
F1731407: Image 071.jpg
Mar 18 2022, 05:23
F1726439: Image 028.jpg
Mar 7 2022, 19:50
F1726437: Image 027.jpg
Mar 7 2022, 19:50
F1726422: Image 025.jpg
Mar 7 2022, 19:23
F1726420: Image 024.jpg
Mar 7 2022, 19:23
F1724662: Image 018.jpg
Mar 3 2022, 22:43

Description

On our private wiki, when using a Cargo query exactly as noted below, we get an exception, but only on page preview (odd).

[dd2329a9a87055d250a905bf] 2022-02-24 19:15:05: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

Steps to reproduce:

  1. Copy the following:
{{#cargo_query:tables=Events
|fields=_pageTitle=Title, type, started, duration, prize, vip, reward, ended, ticket, ticketType
|where=_pageTitle like '%21%'
|limit=10
|named args=yes
|default=No Events to display
}}
  1. Create a new page, paste the content and press preview (not save).
  2. If no exception kicks, please leave/close the page entirely (hitting preview repeatedly on same page or using the browser's back button then re-previewing doesn't work; only complete exit, create page, edit, paste, and preview again works). This may need to be repeated at most 3-4 times to kick exception reliably.

Can someone please provide the (non-sensitive) exception details?
Thanks!

Event Timeline

Reception123 triaged this task as Normal priority.Feb 25 2022, 06:00
Error 1062: Duplicate entry '0-1644' for key 'PRIMARY' (db101)
Function: Wikimedia\Rdbms\Database::insert
Query: INSERT INTO `cargo_backlinks` (cbl_query_page_id,cbl_result_page_id) VALUES (0,'1644')
from /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(1809)
#0 /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(1793): Wikimedia\Rdbms\Database->getQueryException(string, integer, string, string)
#1 /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(1768): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)
#2 /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(1327): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
#3 /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(2540): Wikimedia\Rdbms\Database->query(string, string, integer)
#4 /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(2520): Wikimedia\Rdbms\Database->doInsert(string, array, string)
#5 /srv/mediawiki/w/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->insert(string, array)
#6 /srv/mediawiki/w/includes/libs/rdbms/database/DBConnRef.php(380): Wikimedia\Rdbms\DBConnRef->__call(string, array)
#7 /srv/mediawiki/w/extensions/Cargo/includes/CargoBackLinks.php(45): Wikimedia\Rdbms\DBConnRef->insert(string, array)
#8 /srv/mediawiki/w/extensions/Cargo/includes/parserfunctions/CargoQuery.php(161): CargoBackLinks::setBackLinks(Title, array)
#9 /srv/mediawiki/w/includes/parser/Parser.php(3407): CargoQuery::run(Parser, string, string, string, string, string, string)
#10 /srv/mediawiki/w/includes/parser/Parser.php(3092): Parser->callParserFunction(PPFrame_Hash, string, array)
#11 /srv/mediawiki/w/includes/parser/PPFrame_Hash.php(273): Parser->braceSubstitution(array, PPFrame_Hash)
#12 /srv/mediawiki/w/includes/parser/Parser.php(2930): PPFrame_Hash->expand(PPNode_Hash_Tree, integer)
#13 /srv/mediawiki/w/includes/parser/Parser.php(1598): Parser->replaceVariables(string)
#14 /srv/mediawiki/w/includes/parser/Parser.php(656): Parser->internalParse(string)
#15 /srv/mediawiki/w/includes/content/WikitextContent.php(327): Parser->parse(string, Title, ParserOptions, boolean, boolean, NULL)
#16 /srv/mediawiki/w/includes/content/AbstractContent.php(548): WikitextContent->fillParserOutput(Title, NULL, ParserOptions, boolean, ParserOutput)
#17 /srv/mediawiki/w/includes/EditPage.php(4214): AbstractContent->getParserOutput(Title, NULL, ParserOptions)
#18 /srv/mediawiki/w/includes/EditPage.php(4117): EditPage->doPreviewParse(WikitextContent)
#19 /srv/mediawiki/w/includes/EditPage.php(2895): EditPage->getPreviewText()
#20 /srv/mediawiki/w/includes/EditPage.php(722): EditPage->showEditForm()
#21 /srv/mediawiki/w/includes/actions/EditAction.php(71): EditPage->edit()
#22 /srv/mediawiki/w/includes/actions/SubmitAction.php(38): EditAction->show()
#23 /srv/mediawiki/w/includes/MediaWiki.php(543): SubmitAction->show()
#24 /srv/mediawiki/w/includes/MediaWiki.php(320): MediaWiki->performAction(Article, Title)
#25 /srv/mediawiki/w/includes/MediaWiki.php(930): MediaWiki->performRequest()
#26 /srv/mediawiki/w/includes/MediaWiki.php(564): MediaWiki->main()
#27 /srv/mediawiki/w/index.php(53): MediaWiki->run()
#28 /srv/mediawiki/w/index.php(46): wfIndexMain()
#29 {main}

I think we've had to rebuild tables before for this.

Thanks for adding the details!

I'm trying the on-wiki Cargo table refresh (available for all tables since V 3, where some tables had to be done via command line) to rebuild the cargo tables, and will retest when it has finished to see if this eliminates the errors. I will update the task after I know if it resolves the issue.

Cheers

Thanks for adding the details!

I'm trying the on-wiki Cargo table refresh (available for all tables since V 3, where some tables had to be done via command line) to rebuild the cargo tables, and will retest when it has finished to see if this eliminates the errors. I will update the task after I know if it resolves the issue.

Cheers

Any updates yet? :)

Unfortunately, no. While some tables have populated via job queue, and can be swapped in (the ones with 9k and 14k rows), the old tables remain active until they can be swapped, so I can't test against the new ones. For some reason, the others have gotten stuck repeatedly and refused to populate with all results, so I'm having to redo them one by one, repeatedly after they are stuck for significant lengths of time.

Image 018.jpg (603×906 px, 177 KB)

The tables that won't populate, and can't be swapped, are the ones that trigger the errors. Seems like we may be stuck between a rock and a hard place unless table regeneration is done via SSH.

So would you like us to try via a script in that case?

For the short term, re-creating the tables via cargoRecreateData.php would be very helpful yes, thank you. Then I can see if they populate at all or if the same occurs (the interface method supposedly runs the same, but perhaps some limit or other issue is interrupting its ability to complete or not time out? I think long-term, it might be worthwhile finding out why the tables are not populating, and why job queue reports as having only 3 jobs.

Image 024.jpg (648×998 px, 141 KB)

Despite only 3 jobs in the queue, there are still (many) rows that aren't populating since updating to the new version of MediaWiki (or maybe new version of Cargo, no idea which):

Image 025.jpg (321×716 px, 68 KB)

My questions for Miraheze are:

  1. What are the next steps that a Cargo user on Miraheze should take?
  2. Should Cargo users always create phab tickets to have Cargo tables populated?
  3. Is there some adjustment that can be made on Miraheze for Cargo scripts so that cargoRecreateData.php can run successfully when executed through the front-end as intended?

I'm also wondering if this issue might somehow be related to T8876 ?

Thanks

Here's some interesting info to add now that I'm testing. I waited until job queue was empty then set a table to re-create... initially the correct number of jobs are created that match the number of entries that should populate in the Cargo table (854 jobs, for 854 rows needing to be populated? Is that how it even works?):

Image 027.jpg (680×1 px, 143 KB)

Image 028.jpg (551×911 px, 145 KB)

Then at some point, some of those jobs seem to drop off the queue randomly, and it never finishes populating? Maybe I'm misreading things... it just seems strange that above job queue reports no jobs to populate the missing items. Are some things not making it into the queue maybe?

Just as an update to this, one table is still not populating fully:

Image 071.jpg (95×679 px, 26 KB)

And with job queue reporting as empty (something funky there):

Image 072.jpg (398×391 px, 58 KB)

After multiple tries I was able to get one to populate (Dragons) but our "Events" table is still unable to regardless of retries.

Was a Miraheze volunteer able to recreate the tables via command line? If not, could someone please reacreate the Events table?

Thanks! :)

I'm guessing this problem is related to T8876, rendering cargo unusable for us. I'm mark as stalled (apologies if that's not correct, please feel free to mark as closed because we're not moving forward with MH at this time, will re-test for migration at a later date).

Thanks!

CrystalClear changed the task status from Open to Stalled.Mar 18 2022, 23:13
Unknown Object (User) changed the task status from Stalled to Open.Mar 18 2022, 23:26

Stalled means we're waiting on someone outside of Miraheze to do something so marking as open again as we're not waiting for anyone.

Okay, thanks. I've just unsubscribed and muted since I can't take myself off this, and I can't close it.

Unknown Object (User) subscribed.Mar 20 2022, 10:41

T8460 and T8509 is the same issue I believe.

Unknown Object (User) added a comment.Mar 21 2022, 15:56

@Universal_Omega Do you think this is upstream?

Yes.

Also, I can't re-create the tables via interface, I asked if someone could or would please try that via SSH, but received no response to that ask, so diabled cargo instead.

Please excuse my ignorance, I'm always confused when 'upstream' mention occurs. By upstream, do you mean the issue is with MediaWiki, or with Cargo? Part of the issue for users like myself when a problem reaches this point is, I don't understand where the responsibility lies for reporting and to whom.

I also don't understand the issue well enough to create a decent phab task for it (and I also worry it would be dismissed because I don't understand the issue well enough to write a coherent task, and to put it where it belongs, and, well I have cognitive issues that make writing difficult).

Is it the user (of one of the affected related tasks, I now see several) who should be attempting to create a task on the appropriate WM phabricator for this (if they're able to determine which one), or is this something that Miraheze volunteers do since they understand the issue better?

It would be very helpful for me to try to figure out where my responsibility lies, so I know I'm doing my part adequately.

Thanks

Closing as invalid per T8985 which is a very similar error and there doesn't really seem to be anything that can be done by us at Miraheze to fix this.

Upstream refers to the developers of the extension (Cargo rather than MediaWiki), since we have no control over what they do with it.

The upstream task has been created at https://phabricator.wikimedia.org/T305684 and you should feel free to discuss it there if any developers answer or say anything.