Last modified: 2012-05-03 02:42:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36653, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34653 - API list=logevents does not correctly unserialize log_params
API list=logevents does not correctly unserialize log_params
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.19
All All
: High normal (vote)
: 1.19.0 release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 31217
  Show dependency treegraph
 
Reported: 2012-02-23 20:56 UTC by Rainer Rillke @commons.wikimedia
Modified: 2012-05-03 02:42 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rainer Rillke @commons.wikimedia 2012-02-23 20:56:18 UTC
https://commons.wikimedia.org/w/api.php?action=query&list=logevents&leprop=type|user|timestamp|details&ledir=older&lelimit=100&letitle=File%3AAtlas-Vega+powerd+Trayactory+with+three+stages.png&requestid=File%3AAtlas-Vega+powerd+Trayactory+with+three+stages.png&format=jsonfm
-- corrupt data / no target for action = move returned despite requested details
(what is "0": "a:0:{}", or "cur": "a:3:{s:8:\"4::curid\";i:67418845;s:9:\"5::previd\";i:67418790;s:7:\"6::auto\";i:1;}")

User upload log tells me that "Hypersonic Plane.png" was uploaded on 2012-02-23 15:13:56; in the revision table it is 2012-02-23 15:13:25; same with version 2012-02-22 20:14:18 / 2012-02-22 20:13:57
Comment 1 Mark A. Hershberger 2012-02-24 02:16:00 UTC
What are these logs used for?
Comment 2 Rainer Rillke @commons.wikimedia 2012-02-24 10:59:07 UTC
I use them in my js tools on Commons that then report to users their file has been deleted instead of moved.

But other users may use them for other purposes. Fact is that the API puts garbage out and does not tell me where the file has gone. All file moves since the MW-update seem to be affected.

Good output (moved before update):
https://commons.wikimedia.org/w/api.php?action=query&list=logevents&leprop=type%7Cuser%7Ctimestamp%7Cdetails&ledir=older&lelimit=100&letitle=File%3AAb%C5%82oha+Bera%C5%9Bcia%2C+1657.jpg&requestid=File%3AAb%C5%82oha+Bera%C5%9Bcia%2C+1657.jpg&format=jsonfm

Bad output (moved after update):
https://commons.wikimedia.org/w/api.php?action=query&list=logevents&leprop=type%7Cuser%7Ctimestamp%7Cdetails&ledir=older&lelimit=100&letitle=File%3ACatholic+Church+in+Zembin%2C+Belarus+1.jpg&requestid=File%3ACatholic+Church+in+Zembin%2C+Belarus+1.jpg&format=jsonfm

(no move object move: { new_ns: number, new_title: "String" })

And as pointed out above there are log entry outputs with complete garbage (see "what is ...")
Comment 3 Bryan Tong Minh 2012-02-24 12:09:53 UTC
(In reply to comment #2)
> And as pointed out above there are log entry outputs with complete garbage (see
> "what is ...")

That is the PHP serialization format, not sure if that should be outputted in raw or be unserialized by the API.
Comment 4 Rainer Rillke @commons.wikimedia 2012-02-24 15:24:21 UTC
Ok:
https://commons.wikimedia.org/w/api.php?action=query&list=logevents&leprop=type|user|timestamp|details&ledir=older&lelimit=100&letitle=File:Example.jpg&requestid=File%3AAtlas-Vega+powerd+Trayactory+with+three+stages.png&format=jsonfm
			{
				"type": "patrol",
				"action": "patrol",
				"patrol": {
					"auto": "1",
					"prev": "47639539",
					"cur": "53980345"
				},
				"user": "Bdk",
				"timestamp": "2011-05-04T19:10:01Z"
			},

Wrong:
https://commons.wikimedia.org/w/api.php?action=query&list=logevents&leprop=type|user|timestamp|details&ledir=older&lelimit=100&letitle=File%3AAtlas-Vega+powerd+Trayactory+with+three+stages.png&requestid=File%3AAtlas-Vega+powerd+Trayactory+with+three+stages.png&format=jsonfm
			{
				"type": "patrol",
				"action": "patrol",
				"patrol": {
					"auto": null,
					"prev": null,
					"cur": "a:3:{s:8:\"4::curid\";i:67418845;s:9:\"5::previd\";i:67418790;s:7:\"6::auto\";i:1;}"
				},
				"user": "Uwe W.",
				"timestamp": "2012-02-23T14:00:46Z"
			}
Comment 5 Mark A. Hershberger 2012-02-24 18:04:52 UTC
so, adding the requestid screws this up. Seems like it should be a simple fix.  Thanks for the trouble-shooting.
Comment 6 Rainer Rillke @commons.wikimedia 2012-02-24 18:09:42 UTC
(In reply to comment #5)
Huh? They both have a requestid (forgot to change one)
Comment 7 Rainer Rillke @commons.wikimedia 2012-02-24 18:20:16 UTC
But yes, doing some experiments, you can make it even more strange:

https://commons.wikimedia.org/w/api.php?action=query&list=logevents&leprop=details&lelimit=100&letitle=File%3AAtlas-Vega+powerd+Trayactory+with+three+stages.png&format=jsonfm

	"query": {
		"logevents": [
			[
				"a:0:{}"
			],
			{
				"patrol": {
					"auto": null,
					"prev": null,
					"cur": "a:3:{s:8:\"4::curid\";i:67418845;s:9:\"5::previd\";i:67418790;s:7:\"6::auto\";i:1;}"
				}
			}
		]
	}
Comment 8 Mark A. Hershberger 2012-02-24 18:21:08 UTC
(In reply to comment #6)
> (In reply to comment #5)
> Huh? They both have a requestid (forgot to change one)

Sorry, missed it.  So the difference appears to be:

letitle=File:Example.jpg&
letitle=File%3AAtlas-Vega+powerd+Trayactory+with+three+stages.png&

Removing letitle entirely gets lots of the garbage entries.
Comment 9 Rainer Rillke @commons.wikimedia 2012-02-24 21:27:19 UTC
The following is about one file:

According to  https://commons.wikimedia.org/w/index.php?title=File:Jr-NTR-As-Malabar-Gold-Brand-Ambassador-Stills-13_%281%29.jpg&action=history
 3 files were uploaded under this name; one entry is the initial upload (upload/upload) two are new version-uploads (upload/overwrite)

    (cur | prev) 20:26, 24 February 2012‎ Falcon8765 (talk | contribs | block)‎ . . (341 bytes) (+48)‎ . . (subst) (rollback | undo)
    (cur | prev) 20:25, 24 February 2012‎ Falcon8765 (talk | contribs | block)‎ . . (293 bytes) (+8)‎ . . ({{npd}}) (undo)
    (cur | prev) 19:55, 24 February 2012‎ Aravindsamavedam (talk | contribs | block)‎ . . (285 bytes) (0)‎ . . (Aravindsamavedam uploaded a new version of File:Jr-NTR-As-Malabar-Gold-Brand-Ambassador-Stills-13 (1).jpg: resolution change) (undo)
    (cur | prev) 19:52, 24 February 2012‎ Aravindsamavedam (talk | contribs | block)‎ . . (285 bytes) (0)‎ . . (Aravindsamavedam uploaded a new version of File:Jr-NTR-As-Malabar-Gold-Brand-Ambassador-Stills-13 (1).jpg: {{Information |Description ={{en|1=jr ntr as malabar gold ambassador}} |Source ={{own}} |Author =[[User:Aravindsamavedam|Aravinds) (undo)
    (cur | prev) 19:51, 24 February 2012‎ Aravindsamavedam (talk | contribs | block)‎ . . (285 bytes) (+285)‎ . . ({{Information |Description ={{en|1=jr ntr as malabar gold ambassador}} |Source ={{own}} |Author =Aravindsamavedam |Date = |Permission = |other_versions = }})


----
 https://commons.wikimedia.org/wiki/File:Jr-NTR-As-Malabar-Gold-Brand-Ambassador-Stills-13_(1).jpg#filehistory  shows *4* versions 

----
 The upload log on-wiki  https://commons.wikimedia.org/w/index.php?page=File%3AJr-NTR-As-Malabar-Gold-Brand-Ambassador-Stills-13+%281%29.jpg&title=Special%3ALog  shows *3* entries: All three are of type upload/overwrite (=uploaded a new version of ...)

----

What's going on?
Comment 10 Arthur Richards 2012-02-24 22:45:15 UTC
I'm not sure about the most recent comment, but I've been investigating the issue brought up in the initial comments. It appears that the API for log events has not kept pace with development with the logging classes in MW in general. I'm going to take a stab at cleaning up the issue with serialized output (which appears to be an issue where the API is not properly handling different formats of 'log param' data).
Comment 11 Arthur Richards 2012-02-24 23:41:42 UTC
I've started addressing this issue in r112374. It would probably be best for someone with more experience/knowledge about the logging infrastructure (and the changes that have happened to it 1.19) to take a look at my changes and test.
Comment 12 Arthur Richards 2012-02-25 00:43:17 UTC
(In reply to comment #9)
This is bizarre and the behavior you note with File:Jr-NTR-As-Malabar-Gold-Brand-Ambassador-Stills-13_(1).jpg is inconsistent with the behavior for other files, like File:Wikiportal-Logo-Schweiz.svg (which seems to be logged correctly).

I double checked the logging table in the database for commons. There are only three log records for File:Jr-NTR-As-Malabar-Gold-Brand-Ambassador-Stills-13_(1).jpg (rather than the expected 4). Rainer, have you seen this same bad behavior elsewhere on commons? 

That file was uploaded at 1950 (UTC) on 24 Feb, I suppose it's possible something was happening that prevented log data from getting written to the db (code deployment? db hiccup?) and this might be a one-off event not indicative of something wrong in code. 

Regardless, the issue you bring up in comment #9 appears totally unrelated to the initial issue you raised in this bug.
Comment 13 Mark A. Hershberger 2012-02-25 20:14:08 UTC
(In reply to comment #12)
> Regardless, the issue you bring up in comment #9 appears totally unrelated to
> the initial issue you raised in this bug.

I split off comment 9 and comment 12 into Bug 34713.  If you want to follow up that issue, please use that bug.
Comment 14 Bawolff (Brian Wolff) 2012-02-27 05:38:01 UTC
Without looking into the issue at all... but it sounds like the api was forgotten about when the Logging stuff was re-factored...
Comment 15 Rob Lanphier 2012-02-28 20:03:41 UTC
This one appears to be fixed and deployed.  There are possible other API+logging issues (e.g. the one that Tim fixed in r112546), but lets handle them in separate issues rather than tacking stuff on to this report.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links