Thank you for this! Solved the issue for me.
So the actual issue is that Cachy-Update checks for flatpaks a million times instead of just 5?
No the actual issue is that flathub has problems.
And another issue is that arch-update does not check or fail gracefully.
And also that arch-update looks at flathub at all even if the system has no flatpaks.
Just another reason to not use these kinds of utilities. 
more to DNS issue or Server issue is the likely culprit
like, when you need to contact (for example google.com) and the script will wait until got some return from there, and if the script didn’t get any return it WILL wait, until specific timeout (let say 1 minutes) and yes it will wait for 1 minutes (IF the script has a failsafe if the reached destination was RTO or unreachable)
the good things is, we can disable flatpak check in the config, so just disable it, and arch-update won’t check any flatpak server or any flatpak related in your system.
Ah, ok. Usually I see a ~/ or something like that for these commands that involve usernames.
The file doesn’t exist. I’m fine with waiting for a proper fix in Cachy-Update until Plasma 6.6 is available.
??
It does involve usernames.
$HOME is the same as ~ which is also the same as /home/$YOUR_USERNAME.
The last one is the real path. The others are variables/aliases.
Its not expected to until it is created.
The tool even has options to create and edit them so you dont have to mkdir or anything else manually that have already been shared here at least twice.
It is in no way related to plasma or plasma updates.
I have no idea if this is ever going to be ‘fixed’ or when or in what fashion. But until then or the connection becomes healthy or you apply that option (which apparently everyone should apply anyways unless using flatpak - to save time,cpu,energy,etc if arch-update is going to be a little dumb) it would seem to have a pretty sizable impact on the usability of this tool.
Maybe it will just encourage you and others to use pacman as the Archangels intended. 
==> Procurando atualizações…
Erro ao atualizar: Enquanto executava pull de appstream2/x86_64 a partir do remoto flathub: While fetching htt
ps://dl.flathub.org/repo/delta-indexes/7Q/dJHeoulSA7bChbqpRu7BfixR8VspcMXi_P2BvYkWY.index: [28] Timeout was re
ached
Erro ao atualizar: Enquanto executava pull de appstream2/x86_64 a partir do remoto flathub: While fetching htt
ps://dl.flathub.org/repo/delta-indexes/7Q/dJHeoulSA7bChbqpRu7BfixR8VspcMXi_P2BvYkWY.index: [28] Timeout was re
ached
==> Pacotes:
bluez 5.85-1.1 → 5.86-2.1
Thats what I was asking for.
And it does match the others.
Timed out trying flathub.
Even though you do not have any flatpaks.
You could disable it in the conf file.
Or live with it until something or other changes.
Or return to pacman just. 
sudo pacman -Syu
I guess I should go back to the old
sudo pacman -Syu --noconfirm ; flatpak update -y
Let’s see Limine’s snapshots are good enough for this.
Can I make arch-update.conf use this command instead of its default safe update process?
Now that I updated Cachy-Update is working fast again.
Needed to update before the update utility could work properly? 
( I know it wont always be like that. But it is a circularly difficult position that somewhat invalidates the usefulness or even entire purpose of the tool. And its just a little funny. )
Does this combo of commands reproduce every single thing that Cachy-Update does (with noconfirm added to it)?
paru -Syu --noconfirm ; sudo pacman -Sc --noconfirm ; sudo pacman -Qtdq ; sudo pacman -Rns $(pacman -Qtdq) --noconfirm ; flatpak update -y
For what it’s worth, I do a daily update with arch-update, have no Flatpaks installed, and don’t stop the utility from checking Flatpaks, but I have never encountered this issue.
Feels like it might be a location/routing/DNS issue with Flatpak.
Sorta but that is not how I would form it.
Because all of those that do anything are used with no-confirm .. which is neither recommended nor the same as arch-update which presents you with the action and asks confirmation.
You dont need to add fancy confirmation things .. just executing something like sudo pacman -Syu will do a good job of presenting the packages and download size and ask y/N.
It is also missing news. And what is the point of printing orphans and then just removing them without confirmation? Why not just do something that asks for confirm after presenting them? Something like sudo pacman -Rns $(pacman -Qdtq). It also seems to be missing ‘old’ cache files. At least arch-update seems to indicate its not simple uninstalled cache. Also missing is pacnews and service/reboot checker.
Anyways I would more do something like;
paru -Pw;
sudo pacman -Syu;
paru -Sua;
flatpak update;
sudo pacman -Rns $(pacman -Qdtq);
paccache -rvk2;
sudo pacman -Sc;
DIFFPROG=meld pacdiff -s
Which puts news at the front and pacnews at the end and still does not have a services or kernel reboot checker thing. These would need extra scripting or tools like needrestart. Similarly we could actually check if any orphans exist before prompting/attempting the removal at all and the same goes for pacnews.. but these kinds of things might be considered extra.
So if I want --noconfirm, don’t want news (because I bookmarked them on my browser), and like the spaces between the ; , the replication would be:
sudo pacman -Syu --noconfirm; paru -Sua --noconfirm ; flatpak update -y ; sudo pacman -Rns $(pacman -Qtdq) --noconfirm ; paccache -rvk2 ; sudo pacman -Sc --noconfirm ; echo o | DIFFPROG=meld pacdiff -s
Not quite.
What is the intention here?
Is that an attempted automatic overwrite of the local file with the pacnew?
Besides that its silly to apply a DIFFPROG if you arent going to diff anything..
This is like setting a timebomb.
There is no question that there will be pacnews that if you do this will break sudo or entire user accounts, could render your system unbootable, etc etc.
You absolutely should not use this.
Please revisit any of the other threads where pacnews are discussed or the archwiki.
Anyways .. here is a more sane example.
Heavy emphasis on ‘more’ because --noconfirm is still not sane.
sudo pacman -Syu --noconfirm ; paru -Sua --noconfirm ; flatpak update -y ; sudo pacman -Rns $(pacman -Qdtq) --noconfirm ; paccache -rvk2 ; sudo pacman -Sc --noconfirm ; DIFFPROG=meld pacdiff -s
You were right. Doing my way broke Firefox yesterday, I had to search for some Reddit posts to make it work.