1. Doesn't that completely negate the point of having a cache.
2. On a site with a lot of extension it will potentially time out if you check them all at once.

Isn't it better to find out why there are duplicates and prevent that

Doesn't that completely negate the point of having a cache.

Well the cache is only used as along as the check time out is not runned out.

On a site with a lot of extension it will potentially time out if you check them all at once.

Well this is already the case, but we could only delete the updates we currently try to update as we know wich update site we currently try to reach for updates.

Isn't it better to find out why there are duplicates and prevent that

As said on all logins to the backed that check is runned via ajax, but an usually site does not regularly clear the cache using com_installer.

Doesn't that completely negate the point of having a cache.

Well the cache is only used as along as the check time out is not runned out.

but you are proposing to always clear the cache on login. 5 users log in within 20 minutes and the cache is cleaned 5 times.

On a site with a lot of extension it will potentially time out if you check them all at once.

Well this is already the case, but we could only delete the updates we currently try to update as we know wich update site we currently try to reach for updates.

Not really as the cache starts when the extension is installed so they all expire at different times. There is also the option currently to purge the cache on a per selected extension only

Isn't it better to find out why there are duplicates and prevent that

As said on all logins to the backed that check is runned via ajax, but an usually site does not regularly clear the cache using com_installer.

That should have nothing to do with the creation of duplicates.

Not really as the cache starts when the extension is installed so they all expire at different times. There is also the option currently to purge the cache on a per selected extension only

Where? com_installer purge runs the truncate on #__updates already. https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_installer/models/update.php#L270

but you are proposing to always clear the cache on login. 5 users log in within 20 minutes and the cache is cleaned 5 times.

Sorry this wasn't my intention to suggest. I have said we could do it but i'm not sure whether this would be a good idea, we might also just run a delete query for the update site ID we check before we actually re-check them.

That should have nothing to do with the creation of duplicates.

Are you sure about this? The ajax runs asyncron to the other context in the background. In case you login and logout fast or with different users at the same time (maybe there are also some other factors relevant like response speed of the update servers etc) that we could end up with duplicate entries in the database.

For now when I not missed something we don't remove them regularly anyway so also from this there could be an duplication come from as well as duplicate update_sites pointing to the same update server etc. The later problem for sure should better be fixed by a system like this: #25921 but there are different reasons that duplication can come from.

This here would be just a starting point to trackel this issue.

If the code is correct there never should be a duplication.
If the code is not correct then everyone should see a duplication

The way you are proposing to fix this problem is not addressing the issue but placing a band aid on the system. We have too many band aids.

The way you are proposing to fix this problem is not addressing the issue but placing a band aid on the system.

Well in my point of view this would be the correct response for the truncate suggestion alone, wich I already stepped back in my first post already.
But to me this is not the case for the second suggestion to run a partly delete of the updates table by update_site id etc. as this is something we currently don't do at all and our current system just works because we magically update the entries and don't take into account any removal of updates from the update server at all.

It doesnt address why on some sites you are getting duplicates. You cant really fix a problem if you dont know how it is caused.. You dont fix a leak in the roof with a bucket to catch the rain

What when the leak is that we don't delete the #__updates table at all before checking for new updates?

To me this is a combination of many things:

• Old sites (most date back to 2.5 and even 1.5)
• we don't delete the data unless you hit clear cache from the installer update view
• we check for updates very often even via ajax that could lead into conditions that result into such duplicates that never get deleted.
• It could also been caused by an issue on upgrades or something that happen in the past but in my opinion should be fixed anyway as this is a issue in itself alone.

Fixing the first thing would be something we can address by #25921
The second issue should in my personal option be addressed here by running a delete query that removes the entries from the #__updates table for the update_site id we are about to check for new updates anyway. (DELETE * from #__updates where update_site_id = $theUpdateSiteIDWeNowWhatToCheckForUpdates)
The third issue can be addressed by table locking wich is a different and bigger PR as this is IIRC not Implement into the core yet.
An upgrade issue or issue in a past versions can only be fixed for the old sites by new code like mention above.

If the code is not correct then everyone should see a duplication

Just for the record can you please check your #__updates too? I have just done the check and can confirm this is also the case on my personal site where only me myself and I have access too and it also dates back to 2.5 times too. So that could be an additional notice that something in the history was / is broken and needs to be fixed now for them even when it does not come up on new sites anymore.

Just for the record can you please check your #__updates too?
Oldest client site - updated all the way from 1.6

hmm seams like you have no language updates at all that should would be a different problem.

That's because my site is only English.

Thinking aloud.
Is it possible that languages are installed and not upgraded.
Is it possible that if an extension is uninstalled the update record is not removed and if you install it again later that gives you the duplicate

Is it possible that languages are installed and not upgraded.

I have double checked that now. I have installed the latest version already, but as you can see in my screenshot there is an outdated version of the Slovenian package in the database and two with the latest version.

Is it possible that if an extension is uninstalled the update record is not removed and if you install it again later that gives you the duplicate

This code path should make sure this is not the case:
https://github.com/joomla/joomla-cms/blob/staging/plugins/extension/joomla/joomla.php#L137-L200

I have also not seen this yet with extensions only with languages.

That's because my site is only English.

I have just double checked that the entries for the not installed language packs should exist there anyway as it should exist as update site for en-GB only sites too. (src: https://github.com/joomla/joomla-cms/blob/staging/installation/sql/mysql/joomla.sql#L1993)

Sure it does not find any extension_id so it does not show up as update but the entries should be in the #__updates anyway, just reproduced by an clean 3.9.11 with en-GB only. You might disabled the update site? Can you clear the update cache and than check for updates? The entries should come up on your site too.

Looking again.
The table #__updates shows the available updates
The table #__update_sites shows the links to the update sites

After refreshing etc and enabling some disabled extensions

note it is showing joomla as an available update because that site is still on 3.9.10

Ok I could now finally reproduce the problem on 3.9.11 too, done the patch with instructions now: #25923

If the code is not correct then everyone should see a duplication

Seams this is true but the conditions are not that easy to get but please check this PR (#25923) there you can see the test instructions.

The table #__updates shows the available updates
The table #__update_sites shows the links to the update sites

Yes, correct.

After refreshing etc and enabling some disabled extensions

Is the update site Accredited Joomla! Translations (id 3 on your system) enabled? Can you please manually set the last_check_timestamp to 0 on that update server and just try to get new updates without clear cache.

As the language updates are still missing from your #__updates table.

Thanks for pushing me to find the reason for the duplicate entries so it is easier to test and understand the patch ?

Closed as having Pull Request #25923