Tried this today with a copy of your wiki and it worked fine.

In the Catalyst API logs, I see that when you PATCH your wiki there's an error that's not being surfaced to you! The logs you're seeing (init already ran at least once and last run was successful. Nothing to do) are outdated.

Workaround for you while we figure out the details: Make a copy of your wiki, then you can update it to a new revision and/or remove patches. You should be able to edit that new, copied wiki as normal.

The root cause of this is: your demo was created with an older version of our helm chart and when we try to update your wiki, the configuration is no longer valid for the new version of our helm chart.

This means we should:

• Probably version these things
• Surface this type of error in the UI (which is something we can probably do in the near term)

Details:

We can see the revision history for this wiki:

REVISION    UPDATED                     STATUS        CHART              APP VERSION    DESCRIPTION     
1           Mon Nov 10 18:49:25 2025    superseded    mediawiki-0.1.1                   Install complete
2           Mon Nov 10 21:57:39 2025    superseded    mediawiki-0.1.1                   Upgrade complete
3           Tue Nov 11 07:21:27 2025    deployed      mediawiki-0.1.1                   Upgrade complete

What's missing from the helm history is an update from 2025-12-01, which is what your timestamp in this task shows. That revision is not there because your updates never make it that far.

Which we can see from your attempt to update on 2026-01-15 in the catalyst-api:

[GIN] 2026/01/15 - 08:50:06 | 422 |  245.244754ms |       <patchdemo-ip> | PATCH    "/api/environments/2750"
Error #01: jsonschema: '/db/provided' does not validate with http://www.mediawiki.org/catalyst.mw.schema.json#/properties/db/properties/provided/additionalProperties: additionalProperties 'dbName' not allowed

Which means Catalyst never talks to helm to update your wiki.

In T414659#11539238, @thcipriani wrote:

Workaround for you while we figure out the details: Make a copy of your wiki, then you can update it to a new revision and/or remove patches. You should be able to edit that new, copied wiki as normal.

Thanks :) I've created a copy. I left the old wiki as it is in case Catalyst folks (e.g.) want to do any more debugging/investigating with it, though feel free to delete it once you're finished with it!

Flagging for @jnuche when he's back: we should talk as a group about schema versioning and verification tweaks.

jnuche opened https://gitlab.wikimedia.org/repos/test-platform/catalyst/catalyst-api/-/merge_requests/158

env deploy: associate chart SHA to environment

jnuche merged https://gitlab.wikimedia.org/repos/test-platform/catalyst/catalyst-api/-/merge_requests/158

env deploy: associate chart SHA to environment

The original issue is fixed, but when trying to rebuild 568a59f193 I ran into this:

Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires php >=8.2.0 but your php version (8.1.20) does not satisfy that requirement.
  Problem 2
    - Root composer.json requires lcobucci/jwt 5.6.0 -> satisfiable by lcobucci/jwt[5.6.0].
    - lcobucci/jwt 5.6.0 requires php ~8.2.0 || ~8.3.0 || ~8.4.0 || ~8.5.0 -> your php version (8.1.20) does not satisfy that requirement.

The old chart that 568a59f193 is now pointing to uses older php images that aren't supported by MW anymore. In the future, this issue will affect the recreation of older envs every time MW updates its minimum version requirements.

We could a) parametrize the images used by the chart so a rebuilt env uses the most recent ones, but that will cause some older chart versions that aren't compatible with those images to fail.

We could also b) update an env to the latest chart version when we rebuild it and that should work for the master branches. That has the potential of eventually breaking the code for envs created for the support branches (REL1_39, etc). That being said I just successfully created a REL1_39 env with the latest chart and image versions, so maybe this is not actually a big risk (and if this solution breaks envs with support branches, so should also option a) anyway)

I'll investigate the possibility of implementing option b)

jnuche opened https://gitlab.wikimedia.org/repos/test-platform/catalyst/ci-charts/-/merge_requests/115

use latest images tag in main pod containers

jnuche merged https://gitlab.wikimedia.org/repos/test-platform/catalyst/ci-charts/-/merge_requests/115

use latest images tag in main pod containers

In T414659#11631948, @jnuche wrote:

The fact older branches can still be built hopefully means that the PHP backwards compatibility in MW is systematic (please someone who knows MW correct me if that's wrong).

FWIW, my understanding is that fixes for PHP support in MediaWiki are generally backported to all supported release branches (currently REL1_43/REL1_44/REL1_45). (Unless I'm misunderstanding you & you're referring to something else?)

In T414659#11632424, @A_smart_kitten wrote:

In T414659#11631948, @jnuche wrote:

The fact older branches can still be built hopefully means that the PHP backwards compatibility in MW is systematic (please someone who knows MW correct me if that's wrong).

FWIW, my understanding is that fixes for PHP support in MediaWiki are generally backported to all supported release branches (currently REL1_43/REL1_44/REL1_45). (Unless I'm misunderstanding you & you're referring to something else?)

Sounds like that answers it, yeah. Thanks!

Found this: https://www.mediawiki.org/wiki/Support_policy_for_PHP/Tables I think this is the kind of version matrix we should support in the future, i.e. the image/PHP version should depend on the selected MW version branch