Some initial ideas I discarded for myself:

• CI for PageTriage repository: Seems hard given that the job would either have it or not, and to test its ORES features we do install it. Any form of test declaration would only serve to verify itself and not help prevent issues where it mismatches production.
• Beta Cluster: It may be possible to catch this sort of issue in Beta, and it seems like we already would have, but we don't have a Beta wiki for every prod wiki, and if we would, most of them would likely not have enough traffic to notice that one of the many is broken.

Some other ideas that might work?

• CI for wmf-config repository: It might be possible to detect this in CI for wmf-config. Specifically, the commit enabling the branch could maybe somehow statically detect which extensions are enabled on a wiki, and what their dependencies are and fail the job if dependencies aren't met.
• Deployment (Scap/canary):
  • Endpoint checks: These checks should be run against at least one wiki/hostname in each deployment group (group0-2). This is currently limited to one run, per mediawiki_canary_swagger_url (en.wikipedia).
  • Logstash checks: These Logstash query would've already found the ExtensionDependencyError exception, but presumably didn't trigger due to limited traffic to test2wiki.

CI for wmf-config repository: It might be possible to detect this in CI for wmf-config. Specifically, the commit enabling the branch could maybe somehow statically detect which extensions are enabled on a wiki, and what their dependencies are and fail the job if dependencies aren't met.

+1 for this. It's not a small effort to add this but seems like it would be really useful to avoid these types of problems in the future.