What are these logs used for?

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|user|timestamp|details&ledir=older&lelimit=100&letitle=File:Abłoha Beraścia, 1657.jpg&requestid=File:Abłoha Beraścia, 1657.jpg&format=jsonfm

Bad output (moved after update):
https://commons.wikimedia.org/w/api.php?action=query&list=logevents&leprop=type|user|timestamp|details&ledir=older&lelimit=100&letitle=File:Catholic Church in Zembin, Belarus 1.jpg&requestid=File:Catholic Church in Zembin, 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 ...")

Bryan.TongMinh wrote:

(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.

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:Atlas-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:Atlas-Vega powerd Trayactory with three stages.png&requestid=File:Atlas-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"
			}

so, adding the requestid screws this up. Seems like it should be a simple fix. Thanks for the trouble-shooting.

(In reply to comment #5)
Huh? They both have a requestid (forgot to change one)

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:Atlas-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;}"
				}
			}
		]

}

(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:Atlas-Vega powerd Trayactory with three stages.png&

Removing letitle entirely gets lots of the garbage entries.

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_(1).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:Jr-NTR-As-Malabar-Gold-Brand-Ambassador-Stills-13 (1).jpg&title=Special:Log shows *3* entries: All three are of type upload/overwrite (=uploaded a new version of ...)

What's going on?

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).

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.

(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.

(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.

Without looking into the issue at all... but it sounds like the api was forgotten about when the Logging stuff was re-factored...

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.