Page MenuHomePhabricator

shell.php commands broken
Closed, ResolvedPublicBUG REPORT

Description

None of the PsySH builtins work, which makes debugging less convenient.

$ mwscript shell.php
Psy Shell v0.11.1 (PHP 7.2.31-1+0~20200514.41+debian9~1.gbpe2a56b+wmf1 — cli) by Justin Hileman
>>> ls []
Unknown target: s []

See bobthecow/psysh#705 - caused by a bug in symfony/console 5.4.3, that we upgraded to in rMWVD880f23f482d1: Update symfony/*. We could downgrade, or wait for the next release and upgrade.

Event Timeline

Affects Wikimedia production as well. Probably other MediaWiki installations too.

Tgr updated the task description. (Show Details)
Tgr renamed this task from shell.php commands broken on Vagrant to shell.php commands broken.Feb 9 2022, 8:00 AM
Tgr added a subscriber: Reedy.

@Reedy any thoughts about upgrading vs. downgrading? Looking at the Symfony release cadence the next release is probably 2-3 weeks away. On Vagrant downgrading probably won't help much because of T178137: MediaWiki-Vendor creates a scenario in which incompatible versions of dependencies can be present but it should fix most other environments. Not sure if it's worth the hassle for a couple of weeks though.

If a feature that people use is broken, we should at least partially revert. With vendor, it’s probably easiest to just drop symfony/console a .1 and then upgrade past the broken version

It’s minimal effort, so I’ll do that now

For other usages, we can just temporarily pin it in MW cores composed.json and revert it out when there’s a newer release that composer will just pull in itself

psysh could add the broken versions to conflicts (or whatever the composer function for it is) too…

Change 761314 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/vendor@master] Downgrading symfony/console (v5.4.3 => v5.4.2)

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

Change 761314 merged by jenkins-bot:

[mediawiki/vendor@master] Downgrading symfony/console (v5.4.3 => v5.4.2)

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

Change 761317 merged by jenkins-bot:

[mediawiki/vendor@wmf/1.38.0-wmf.21] Downgrading symfony/console (v5.4.3 => v5.4.2)

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

Mentioned in SAL (#wikimedia-operations) [2022-02-09T13:36:37Z] <reedy@deploy1002> Started scap: Downgrading symfony/console \(v5.4.3 => v5.4.2\) T301320

Mentioned in SAL (#wikimedia-operations) [2022-02-09T13:38:12Z] <reedy@deploy1002> Finished scap: Downgrading symfony/console \(v5.4.3 => v5.4.2\) T301320 (duration: 01m 34s)

Change 761330 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/vendor@wmf/1.38.0-wmf.20] Downgrading symfony/console (v5.4.3 => v5.4.2)

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

Change 761330 merged by jenkins-bot:

[mediawiki/vendor@wmf/1.38.0-wmf.20] Downgrading symfony/console (v5.4.3 => v5.4.2)

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

Mentioned in SAL (#wikimedia-operations) [2022-02-09T14:20:45Z] <reedy@deploy1002> Started scap: Downgrading symfony/console (v5.4.3 => v5.4.2) T301320

Mentioned in SAL (#wikimedia-operations) [2022-02-09T14:22:17Z] <reedy@deploy1002> Finished scap: Downgrading symfony/console (v5.4.3 => v5.4.2) T301320 (duration: 01m 31s)

That's master of vendor, and the two active WMF branches fixed.

"conflict": {
    "symfony/console": "4.4.37 || 5.3.14 || 5.4.3 || 6.0.3"
},

^ Something like the above (I don't know if we need all those version numbers) is probably about the only thing we can do for MW master and/or Vagrant

Thanks for the quick fix!

For Vagrant we'd have to downgrade/pin/conflict for every extension that (directly or indirectly) depends on symfony/console as composer is run for each extension separately and then it's somewhat random which vendor directory is seen first by the autoloader. I don't think that's worth the effort.

Reedy claimed this task.

Going to close it on that regard then.

And then (unfortunately) chalk the other issues upto known pain points.

Thanks for mentioning the conflicts upstream, so maybe we'll get that as a nice fix.