After updating to 11.3.10, available updates page shows 11.3.9 as a newer version

Everything could be strange until packaging is done and update status data is refreshed. This probably solves itself :-)

Feel free to re-open if it doesn't.

See it too.

I'm not sure there's much update.module can do about this. This is because folks (rightly) upgraded as soon as composer saw the new releases. But since the d.o packaging stuff is still running, the latest aren't yet visible in the release history feeds at updates.drupal.org.

It's a little weird to add code to update.module to handle this, but certainly lots of folks were confused in Slack about it. So maybe it's worth a special case for "looks like you're running something bleeding edge, before the release history knows about it... here's a biscuit." more or less. 😂

Looks fine now for me.

Packaging for these releases is not complete. Please check back tomorrow, refresh your site's update data, and see if this problem still occurs then. Thanks!

There's no more info needed. We all understand 100% what's happening here. People upgraded before the releases landed in the release history feeds.

I'm open to the (small) possibility it's worth adding a special case in update.module to report something else than what the IS/screenshot shows during these short (but highly stressful) windows when "everyone" is freaking out. 😅 That's the only question we still need to assess and resolve.

Related possible discussions:

Consider not pushing to Packagist until the D.O. side is ready.

Investigate solving the reported issue that releases currently have to be built serially (which appears to be an underlying trigger for this)

Note: this issue was raised last month on Slack with the security team.

Would this (or something similar) be an improvement? It's a 6 line diff if we want this. We'd need to add tests for it, which would make it more than 6 lines. 😅 Wanted feedback on if this is worth pursuing. Not worth an MR and spending CI cycles on this until we're a little closer to agreement on if/what we should do in this situation.

Consider not pushing to Packagist until the D.O. side is ready.

This is a chicken-and-egg problem because what the "d.o side" is blocked on for a lot of the time between push and "release node published" is... subtree splits and preparing the packages for Packagist. The tags need to exist in a public repo for Packagist to make anything out of them.

Also, as a reminder, the Security Team has no control over either core or d.o infrastructure.

@dww, switching to RM hat, I honestly have no idea what that change set is doing without test coverage. :D Manual testing would also help but that is always a huge fuss if we have to fake update data also.

Honestly, I don't think this is that big of an issue. Caches gonna cache. The only reason that this is even noticeable is that (a) we are supporting 2x as many branches as we ever did before (or even more than that for today's release) and (b) packaging times were upgraded for the new d.o, but as a side effect they are now taking close to 30 mins per core release instead of 11-12.

Hopefully, future optimizations will reduce packaging times again so that people don't get so antsy about it during the window.

Because I refuse to use LLMs to generate slop, and I didn’t want to bother updating test coverage if it’s gonna be shot down. 😅 I didn’t seriously think anyone was going to commit this patch directly. It’s a PoC. If this issue is “works as designed”, so be it. I’m only trying to show it’s not that hard to improve this situation if we wanted to.

Usability review

We discussed this issue briefly at #3590325: Drupal Usability Meeting 2026-05-22. That issue will have a link to a recording of the meeting. The attendees at the usability meeting were benjifisher, rkoller, and simohell. I am giving them credit on this issue.

Besides the comments on Slack around this week's security release, one of us has run into this problem with client sites during previous updates. Perhaps it comes up more frequently than we have been assuming. When it does come up when installing a security release, it is a stressful time, so anything we can do to make it easier is a good idea.

We feel that the proposed change is a useful improvement to the report page. I am adding the Usability tag. Of course, that usability opinion has to be balanced against the reservations from the release manager in earlier comments.

Looking at the mockup (Comment #11), the text meets the standard requirements for a status message: it says what the current state is and it recommends what to do about it. But there is room for improvement:

1. Move the warning message outside the table, perhaps to the messages area. (Warning does seem to be the right message level.)
2. Use full sentences, and start a new sentence instead of using a "comma splice".
3. Do not use the phrase "Current release". Be explicit about the version you mean.

We did not have time at the meeting to come up with a firm suggestion, but you can use this as a starting point for the message text:

The installed release (10.6.9) is not in the feed of available releases. Try again later, or check manually.

(There is a link to "Check manually" on the same page, so I think the last recommendation is actionable. I think I saw a comment on Slack from dww that it is a useful thing to try. It might even be worth repeating the link next to the "Last checked" timestamp.)

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Back to NW to consider the recommendations in Comment #15.

Thanks for the Usability Review! Responding to the specific suggestions for improvement:

1. It's a little weird to move this message outside the table, since in theory it could be true of multiple projects installed on a site. It also makes the implementation a bit harder (not impossible, will just require a bigger diff to implement). If we make this a message at the top of the page instead of inline in the table, we're going to have to have the message list the project name and the version (not just the version as your suggestion), and we'll have to handle the case where this same status is true for multiple projects (e.g. as a <ul> or something. We'll also still have to do *something* with the row in the table, since we can't leave it as-is. We'll probably want to hide the "recommended version", info about "missing" security updates (since we don't actually know if they're missing or not), etc. I think we'll basically need something like the screenshot from #11 inside the table, and then perhaps *also* a warning at the top of the page about it.
2. Full sentences are good. 😅
3. I like the suggestion of saying exactly what release we're talking about.

Also, I *thought* we had logic somewhere in Update Status to remember the mtime on the .info.yml files (or something), so that we know to try to re-fetch the history if the .info.yml file is newer than the last time we checked for available updates. However, the screenshot from #11 is from a local test site where this happened, but it still happens even after the new release started appearing in the feed. Maybe that's because I installed the security update locally as soon as it appeared in composer, then checked available updates, and then Update Status remembered that timestamp from the window-of-weirdness. But yeah, one needs to 'Check manually' to force a re-fetch of available updates. So it's not necessarily only a problem directly during the window between release visible to packagist and release history XML being updated. Caches gonna cache, for sure. But that means that packaging optimizations aren't going to entirely solve this, even if we shrink the size of the weirdness-window.

p.s. Just to say, that means #11 did get manually testing, at least from me. 😉 That's not a mockup and imaginary text created in a vacuum, that's an actual screenshot from an actual Available Updates report from a real site in the weird state.

I should have referred to it as a screenshot, not a mockup.

There are several reasons the recommendations in Comment #15 are tentative:

• There were only 3 participants in the usability meeting.
• As I said, the discussion of this issue was brief.
• We were working from a screenshot, not a live test.

So feel free to keep the message inside the table for the reasons you listed. Can it be full-width inside the table? If I imagine the screenshot with longer text that wraps to a second line, then it looks a little awkward.