Rate limit reached

[emersion]

Affected Version

yay v9.0.1 - libalpm v11.0.1

Issue

When a lot of packages with alternative are installed with --noconfirm, the install can fail with "Rate limit reached".

Steps to reproduce

It may or may not happen depending on your connection.

yay --needed --noconfirm -Syu cmake pkgconf go dep mingw-w64-gcc mingw-w64-cairo-bootstrap mingw-w64-freetype2-bootstrap mingw-w64-gtk3 git

Output

"Rate limit reached"

https://builds.sr.ht/~delthas/job/17160

[Jguer]

For many cases it wouldn't be necessary, for that case maybe pausing yay like we do when the db lock is in place is the best solution

EDIT: This is a rate-limit on 24h , not on burst

[emersion]

Hmm. It seems this build entered a dependency cycle somehow. For instance grep for lib32-libdrm in the logs, you'll see that the alternative is asked multiple times.

[Morganamilo]

If that's due to the provides searching, you could try with --noprovides it's pointless anyway when using --noconfirm. mingw stuff is known to cycle.

[eli-schwartz]

For many cases what wouldn't be necessary? What is pausing anything going to do?

The AUR is rate-limited -- you get 4000 requests per 24-hour period, and unless you want to pause yay for a day I'm not sure what solution you are visualizing.

The problem uncovered by the build in question seems to be that yay manages to submit far too many API requests in rapid succession. That's what a rate limit deals with, after all. Those loops and provides queries look suspicious...

(The rate limit was initially established to prevent abuse like running cower -u in a tight loop inside of terrible conky scripts in order to get update notifications that update like every second. Apparently it may now be doing double duty exposing inefficiencies in AUR helpers.)

[emersion]

If that's due to the provides searching, you could try with --noprovides it's pointless anyway when using --noconfirm. mingw stuff is known to cycle.

Indeed, that seems to be the case. Would you consider automatically adding --noprovides when --noconfirm is used?

[Morganamilo]

Would you consider automatically adding --noprovides when --noconfirm is used?

Sure, it is pointless after all. It was kind of a known bug that there can be some funkiness with self providing dep cycles. I never thought about adding --noconfirm into that.

Yay should be caching rpc requests though, so it sounds like there may be another bug there sadly.

[emersion]

Hmm, just thought that maybe using --noconfirm with --provides can be useful in some cases, for instance when the package itself doesn't exist but -git does.

[Morganamilo]

That's true. Maybe actually fixing the infinite loop when dep cycles are hit should just be done instead.

[eli-schwartz]

Using --noconfirm should definitely not be looking up anything if it could already find a suitable package...

(But I don't really get the point of supporting them to begin with, the AUR is not feature-compatible with actual binary repos and I wouldn't expect replaces to work either.)

[Morganamilo]

Using --noconfirm should definitely not be looking up anything if it could already find a suitable package...

What if that suitable package is itself? The problem occurs with dep cycles that provide something and also depend on it.

Package foo depends on bar and provides bar. the dependency bar ends up being resolved back to foo and it loops forever. It's a bug, quite a nasty one seems as you end up being rate limited. Luckily though it is isolated to this edge case.

[Morganamilo]

With #866 the depsolver should again no longer be able to get stuck in a loop.

[ddevault]

Thanks!

[skuzzymiglet]

This is still happening to me.

It's just happening on every operation. It's happeed a few times and I don't know what caused it

EDIT: I rebooted and the problem remains. There are no pending updates

[45poplar]

The same to me.
I've just upgrade yay from the archlinuxcn repo on archlinux.

[list17]

I just encountered this problem too.
The version: yay v10.1.2 - libalpm v12.0.2

[QuarticCat]

Same as @list17

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[seiuneko]

The same to me.

[Jguer]

Solved with provides changes. New RPC endpoint and new engine should bring this under control