When I test this locally, they get added to the job queue...

Unable to proceed
You do not have permission to move this page, for the following reason:

You do not have permission to move files.

Sigh.

Well, can't test on Commons.

Apparently there's some giant JavaScript thing that sends a request to someone, somewhere, who might move it some time. We'll see.

@brion Dug this up out of the old stuff. Based on recent logs, this still happens... since we repurged all the file pages of videos with no transcodes, I have been watching the move log and resetting the recent moves.

I'll give some examples when I next see it.

Change #1015144 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/TimedMediaHandler@master] Requeue transcodes after file/page move

https://gerrit.wikimedia.org/r/1015144

Change #1015144 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Requeue transcodes after file/page move

https://gerrit.wikimedia.org/r/1015144

This should be fixed once the change rolls out this week.

hmm. or not. I moved this file https://test.wikipedia.org/wiki/File:Bear_av1_renamed.webm

and it doesn't seem to have enqueued new transcode rows. strange as locally it seemed to work will have to dive deeper i guess.

I forgot about database latency of course. I should probably do findfile with the latest: true annotation.

Change #1017151 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/TimedMediaHandler@master] Ignore redirects and ensure we use latests DB state when required

https://gerrit.wikimedia.org/r/1017151

Change #1017151 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Ignore redirects and ensure we use latests DB state when required

https://gerrit.wikimedia.org/r/1017151

Still not fixed in wmf production. Any further ideas @bvibber ?

The one thing i was thinking, is that maybe the new page is created before the file is done moving ? Or something to do with transaction flushing of the db state ? do we literally need to wait for replication to catch up ? I'm kinda lost now.

I uploaded a series of large videos then moved them.
The first ones which were already transcoded had the unknown status and I had to reset them manually (eg: https://commons.wikimedia.org/wiki/File:Atsug%C3%A1_2024-05-28_concert_in_Louvain-la-Neuve_-_01_-_Feel_the_road_(C0643-stabilized.av1.crf6).webm ), the last ones which were still in the queue got transcoded normally when their time came (eg: https://commons.wikimedia.org/wiki/File:Atsug%C3%A1_2024-05-28_concert_in_Louvain-la-Neuve_-_09_-_Angels_and_Demons_(C0652-stabilized.av1.crf6).webm )

Change #1037900 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/TimedMediaHandler@master] Fix "Unknown status" transcodes after move or reupload

https://gerrit.wikimedia.org/r/1037900

@bvibber i gave it another shot, let me know what you think of this idea.

Change #1037900 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Fix "Unknown status" transcodes after move or reupload

https://gerrit.wikimedia.org/r/1037900

Ok. ALSO doesn't work on test.wp.

My last guess then is that for

public function onPageMoveComplete( $old, $new, $user, $pageid, $redirid, $reason, $revision ) {
		if ( $this->transcodableChecker->isTranscodableTitle( $new ) ) {
			$newFile = $this->repoGroup->findFile( $new, [ 'ignoreRedirect' => true, 'latest' => true ] );
			WebVideoTranscode::startJobQueue( $newFile );
		}
	}

this whole find file is not finding the new file yet. and therefore the whole job is never inserted... We can add some log lines for this I guess ?

Why are transcoded regenerated instead of moved to their new location?