feature: allow per task wait

[i3d]

Did you check the docs?

• I have read all the lazy.nvim docs

Is your feature request related to a problem? Please describe.

no, not a problem per sa, but it is a fairly unfortunate situation. We have workstations in cloud that only has limited network bandwidth and the VMs can't allow short high burst of egress traffic. Unfortunately, even if with checker.concurrency = 1, since each check is really fast, the overall speed is still too fast and bursty.

Describe the solution you'd like

It would be nice along with concurrency, we could specify a wait interval to further slow checkers down. e.g. if we could achieve some 1 task per 1s, that should help tremendously, or every time we just got 403 from github.

Describe alternatives you've considered

It does not appear one from the lazy doc. I've limited the task to 1 and still just too fast. Most of time, before all working checks done, the network already got disconnected.

Additional context

No response

[i3d]

FYI, there is already a 'wait' stanza, unfortunately, that's not good enough.

error we got

fatal: unable to access 'https://github.com/stevearc/oil.nvim.git/': Failed to connect to github.com port 443 after 19477 ms: Couldn't connect to server

This typically means we've burst too much :(

[Shougo]

Unfortunately, even if with checker.concurrency = 1, since each check is really fast, the overall speed is still too fast and bursty.

lazy.nvim/doc/lazy.nvim.txt

Line 638 in d1de92d

concurrency = jit.os:find("Windows") and (vim.uv.available_parallelism() * 2) or nil,

The second concurrency option exists. It may work.

[i3d]

I already have

require('lazy').setup('plugins',
  { concurrency = 1, checker = { enabled = true, concurrency = 1, frequency = 2 * 86400, wait = true }, })

still too fast once checker is in working

[Shougo]

Oh..

[folke]

I'll see to add something for this this evening

[mimikun]

I have a similar issue. In my case, I use HDD for disk and have limited network bandwidth.
It would be nice to have an option to select the previous behavior.

[folke]

@mimikun what do you mean with previous behavior?

[mimikun]

Before this commit: 0614ca6

After this commit, my plugin update speed, which was set to concurrency = 1, became incredibly slow (I've now tweaked it a bit and it's gotten a bit better. about: https://github.com/mimikun/dotfiles/blob/f64ba2b10333a65bc06e76aeefbb15f8ecdcdc99/dot_config/nvim/lua/core/lazyvim.lua#L4-L17).

[kdheepak]

I don't mean to pile on because this might certainly not be in scope for this plugin, but my corporate VPN too seems to be blocking :Lazy update.

I have the settings suggested above:

require("lazy").setup({
  concurrency = 1,
  checker = { enabled = true, concurrency = 1, frequency = 2 * 86400, wait = true },
  ...
})

The first few fetchs work fine and then once something fails it continues to fail. I checked with IT and they said the system was flagging these requests as suspicious.

If I'm off my company VPN it works fine so this isn't a deal breaker for me personally, just an annoyance.

[i3d]

Thank you folke! Life saving for us programming inside controlled environments, now I can have a way to tweak to the near allowed capacity and not got banded by our network policy!

One thing to point out, my previous config was like this

require("lazy").setup({
  concurrency = 1,
  checker = { enabled = true, concurrency = 1, frequency = 2 * 86400, wait = true },
  ...
})

The concurrency = 1 on the top-level needs to be taken out or it does not seem to honor the throttle. The concurrency = 1 inside checker seems fine, leaving out there still seem to honor the throttle.

Thank you again!!