while moving and editing.
Please cf. to https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors and
https://commons.wikimedia.org/wiki/User_talk:Rillke/Discuss/2013#DelReqHandler_issues
Sounds like something is rotten in the servers. Super annoying for our hard-working volunteer admins at Commons.
Version: wmf-deployment
Severity: critical
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=13921
Different ones. I am not in the mood doing lot of the work staff could do when looking at our scripts that are all open source. Note that the error is not reproducible. It _seems_ to occur randomly but it could be also related to e.g. only one of your servers etc. Here are some params used:
movePage - indicates that action=move is used, format=json, and all the required params for action=move +watchlist param
Since delReqHandler does not tell me which query/action it is doing when failing, I can't add any further information. It lost it's maintainer and I am too busy with other stuff currently and a proper API client implementation with error reporter is considered "low priority" from the staff side. I can only tell you that it does *not* use https://commons.wikimedia.org/wiki/MediaWiki:Gadget-libAPI.js (which features automatic retry and error analysis); that's why even simple queries may fail.
So here are the links to the source code:
(In reply to comment #2)
Different ones. I am not in the mood doing lot of the work staff could do
when
looking at our scripts that are all open source.
If you don't share some basic info to reproduce it sounds like a pretty bad use of time to let "the work staff" try all potential ways for you.
So here are the links to the source code:
(makes use of the "libAPI" gadget module mentioned before)
Ah, thanks!
(In reply to comment #3)
Andre, I really can't understand that the WMF spends hundred thousands of dollars for questionable projects and claims to care about the "technical side" properly but obviously does not. This is so frustrating.
Isn't it possible to log each occurrence of an API error with all the information required for proper debugging in some kind of database you keep for let's say one month? Betting users to collect and say EVERYTHING they did is not the best method and Firefox, windows etc. have crash reporters that usually do the job for them.
I would really like to see something like "An internal API error occurred and our technical staff was notified and will fix the issue as soon as possible." - This would be a proper service. If I should write an essay and collecting more opinions about the technical support from the "paid side", please let me know. I would be glad if more such core features would be developed.
Besides that, if I read the report on my talk page, I think it's about action=edit (which is the sole thing involved while closing a request).
(In reply to comment #4)
the WMF [...] claims to care about the "technical side" properly but obviously does not.
Haha, you think this includes the obligation to do the work of a bug reporter for them?
(In reply to comment #6)
WHOLE POST IS OFF TOPIC:
No, this means doing their work avoiding *internal*-API-database-query-errors or at least having them automatically notified when an *internal* error occurs. I am not requesting a feature or so; this is standard in other WCMSs.
Also it would be kind if you would carefully read the full text, I posted: The bug reporter would have a much easier job if some kind of tool would allow collecting and transmitting all these boring technical information.
I am sure you are convinced that you run a super service. During the past 3 years things got better but they are still not the way I expect and you should be happy in some way that you still get bug reports at all; if you don't want any feedback than close bugzilla for non-stuff members.
after reading more frustrated postings by [[User:INeverCry]], it is now clear to me that action=delete fails, not action=edit.
(In reply to comment #1)
What query are you even using? Parameters etc?
No query. action=delete using the title and all other required parameters.
Someone observed a pattern when deleting using the VisualFileChange tool.
Here it is:
11 succeeded 4 failed (with API request failed (internal_api_error_DBQueryError): Database query error) 12 succeeded 4 failed (with the same error) 1 succeeded
It may be just one out of your API server collection? I try getting the "servedby"-response included in the next reports.
I've been getting similar the same error (some DBQeryError) with my mass deletion tool. It's written in Java, multi-threaded, and only seems to encounter said errors when multiple deletion queries are made simultaneously. It's possible this is a performance/resource allocation issue.
rd232 wrote:
Raising importance and priority because this has been open a month and NOT BEING ABLE TO EASILY DELETE THINGS IS A BIG PROBLEM.
(In reply to comment #12)
API response:
-error code: internal_api_error_DBQueryError
-error message: Database query error
(server time: Mon, 01 Apr 2013 16:25:21 GMT)
more occurences at https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors (simply search for "internal_api_error_DBQueryError")
This is an example of the response I get when a deletion fails with a DBQeryError. Please fix.
(In reply to comment #12)
With "shell user", you mean someone using the UI? The API? ...?
(In reply to comment #15)
(In reply to comment #12)
With "shell user", you mean someone using the UI? The API? ...?
Someone with shell access on the servers and the ability to look at the log files which store things like database errors.
I don't see a reason to suddenly bump this issue to highest prio, as it has been existing for months and there's no indicators that situation has gotten worse in the last days. This doesn't mean that it shouldn't get fixed though.
(In reply to comment #17)
I don't see a reason to suddenly bump this issue to highest prio, as it has
been existing for months and there's no indicators that situation has gotten
worse in the last days. This doesn't mean that it shouldn't get fixed though.
I agree that it's probably not critical, but this should be investigated. Copying Sam, Rob L., and Tim on this bug. It's gonna require someone looking at the backend to figure out what database query is erroring and why.
inevercry.commons wrote:
(In reply to comment #18)
(In reply to comment #17)
I don't see a reason to suddenly bump this issue to highest prio, as it has
been existing for months and there's no indicators that situation has gotten
worse in the last days. This doesn't mean that it shouldn't get fixed though.I agree that it's probably not critical, but this should be investigated.
Copying Sam, Rob L., and Tim on this bug. It's gonna require someone looking
at
the backend to figure out what database query is erroring and why.
This bug limits Commons admins' ability to delete copyright violations and other problem images. There are 1000s of these images on Commons right now. This bug limits mine and other's ability to help get rid of them. If not critical, I'd atleast say this is highly important.
According to moogsi, the following more descriptive error message is shown in the UI:
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "WikiPage::updateCategoryCounts". Database returned error "1213: Deadlock found when trying to get lock; try restarting transaction (10.64.16.27)".
(In reply to comment #20)
According to moogsi, the following more descriptive error message is shown in
the UI:A database query syntax error has occurred. This may indicate a bug in the
software. The last attempted database query was:(SQL query hidden)from within function "WikiPage::updateCategoryCounts". Database returned error
"1213: Deadlock found when trying to get lock; try restarting transaction
(10.64.16.27)".
I believe this is bug 13921.
Yes, we do have logs, and it's not hard to see that this started happening a lot more often a couple of days before the bug was filed:
http://paste.tstarling.com/p/yVUjkB.html
It is somewhat alarming that it has taken a month of 200 errors per day for a developer to be added to the CC list.
By searching the exception backtraces for ApiDelete::delete, I can confirm that this is identical to bug 13921. For example, in the April 11 log, I see 71 from WikiPage::updateCategoryCounts(), 12 from Title::invalidateCache() and 8 from RecentChange::save(), so pretty much the same as bug 13921 comments 12 and 13.