Update manager crashing admin panel with uncaught exceptions parsing version strings

Thanks for the report, this relates to the recent opening of the main branch. I think this will have to be fixed server side given code that is out in the wild is already crashing.

Confirming this on D8.9.20.

Navigating to any admin page yields a white screen of death:

The "main" version string, it seems, throws an UnexpectedValueException in vendor/composer/semver/src/VersionParser::normalize(), called by core/modules/update/src/ProjectCoreCompatibility::getPossibleCoreUpdateVersions().

Opened #3567494: Filter main branch from the list of core releases to solve this on the drupal.org side, but we should also make the update parser more lenient in core.

A temporary fix for existing sites is to uninstall the update module. That will make things work except for disabling update notifications.

I think this was fixed in 10.3 onwards with #3112962: Core compatibility messages on contrib available updates should consider supported branches - main is not marked as supported in the update XML, so it is filtered out before we try to compare it.

This doesn't help users on 10.2 and earlier where the fix still needs to be implemented server side.

A temporary fix either you uninstall the update module or go to

vendor\composer\semver\src\VersionParser.php

add one more condition after line number 109

if (null === $fullVersion) {
$fullVersion = $version;
}
+ if ($version === 'main'){return 'dev-main';}
// strip off aliasing

Confirmed on a site running 10.2.5. Disabling the update module did the trick \o/

To confirm, #3567494: Filter main branch from the list of core releases is deployed on the drupal.org side and the CDN is serving XML that no longer causes the crash, but it's possible that some sites will still have the XML cached locally in their update.module.

Marking this as fixed, it's unfortunate this broke some older sites but the code path appears fine on 10.3 and above so there is nothing more for us to do here.

I disagree this is fixed.

There is a difference between accidentally avoided and a root cause solution.

The core updates.xml file is provided by a source outside of Drupal Core that is subject to:

• Accidentally providing malformed data
• Being intentionally hacked
• Interception through a Man-In-The-Middle attack.

As an example if have 11.3.x deployed and add a 11.2.32.a.b.c. release to the update.xml the exception is still thrown taking down site administration with a WSOD.

Drupal Core must expect this to occur in the future and either provide validation of externally sourced data or exception handling.

Tested in 11.3.2 providing an intentionally malformed update.xml to Core (changed UpdateManager::buildFetchUrl() to pull from a local server for simulation purposes of either the 3 above incidents occurring)

<release>
      <name>drupal 11.3.1</name>
      <version>11.2.32.a.b.c</version>
      <tag>11.3.1</tag>
...

Update module could either validate the version prior to comparison, or probably better: catch the exception and then log the exception message. Depends whether composer offers exactly the same validation it uses to throw that exception as a public API or not probably.

Yeah, these uncaught exceptions have really bothered me ever since the code that was throwing them was added to Update Status. Let's resolve that that before we call this issue fixed. A "faulty" or unexpected release history feed should never be able to crash a site. Sort of related to #3564803: Fatal error when unable to fetch release history in that sense.

Disclaimer: this MR was assisted by Claude Code.

The MR worked to fix a recent issue when the Suggestion module made an alpha release with an invalid version constraint.

This could be any release for any module a site has installed that could take down the site if a module has a syntax error in the info file.

MR mostly looks good. 1 small question, but probably still RTBC.

Needs subsystem maintainer review 😉

Oh yeah, also not sure about trying to log anything in the error cases. That’s probably a good idea. Only on my phone right now, not so easy to look around and propose specifics. But bumping back to NR for now.

Answered the question, back to RTBC!

@longwave, what about #22? Can we log errors when we catch exceptions?

I guess there’s nothing site admins can do to resolve these errors. So maybe logging them is pointless. But at least then there might be some evidence of a problem, folks could open issues in the upstream issue queues to get new releases.

However, I since we never remove releases, once a faulty release is in the feed, it’ll throw these exceptions forever.

I’m torn. Open to commit this as-is. But curious to get more discussion on this point.

Yeah there is nothing the site owner can do, so I think silently skipping bad data is probably the best thing?

Probably, yeah. Since the site owner can’t fix it, it’s mostly only noise in their logs.

Meanwhile, haven’t tried it at all, but what happens if you install a release with a “bad” version? Does that cause an uncaught exception somewhere else? Or is parsing the feed the only spot this can happen?

Finally back home and had a chance to do more testing.

1. A "faulty" version string doesn't break update status. Putting this in a local test site's copy of address.info.yml:

version: main

results in:

So that's fine, even in D10, etc. 🎉

2. The broken .info file from suggestion 4.2.0-alpha1 (referenced in comment #19) breaks a lot more than update status. Status report, extend page, and many others (not due to update_page_top() -- I removed that from my local test site) are all exploding along these lines:

Drupal\Core\Extension\InfoParserException: The 'core_version_requirement' constraint (^10 - drupal:block - drupal:field) is not a valid value in modules/contrib/address/address.info.yml in Drupal\Core\Extension\InfoParserDynamic->parse() (line 77 of core/lib/Drupal/Core/Extension/InfoParserDynamic.php).
Drupal\Core\Extension\InfoParser->parse('modules/contrib/address/address.info.yml') (Line: 551)
Drupal\Core\Extension\ExtensionList->createExtensionInfo(Object) (Line: 317)
Drupal\Core\Extension\ExtensionList->doList() (Line: 155)
Drupal\Core\Extension\ModuleExtensionList->doList() (Line: 283)
Drupal\Core\Extension\ExtensionList->getList() (Line: 109)

Not sure if we should be catching that exception and logging, or what. Maybe uncaught exceptions in this case are reasonable? Certainly fodder for a follow-up, not in scope here. But pointing out that broken .info.yml files impact a lot more of core than update status alone.

Given all that, moving this back to RTBC. The scope here of uncaught exceptions while parsing the update status feed are fixed by the current MR. Faulty .info.yml can still bring down a site, but that's for a follow-up (or an existing issue I haven't searched for, yet).

Thanks!
-Derek

Just to be clear, we didn't have the version of the code with the faulty version installed.

It was merely that a module we were using on our site made a release with a faulty version. The update module automatically (scheduled cron job) pulled an XML file containing releases for the modules installed (including the faulty one) and the site started throwing 500 errors.

The 500 errors can be avoided by catching the exceptions.

Re: #29 thanks. That was and is absolutely clear. That’s all the existing MR fixes. The point of my comment at the end of #27 and #28 was to wonder & investigate what else might be broken along similar lines, before I sign off on this bugfix. 😅 thankfully, the answer is “nothing else specific to Update Status, but potentially lots of other things that are out of scope here”. Hence, setting this to RTBC.

Thanks again,
-Derek

Alrighty - thank you. Yes, I imagine this could have other implications. :/

This looks good.

Committed/pushed to main, 11.x, 11.4.x, and 10.6.x, thanks!