Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: allow per task wait #1635

Closed
1 task done
i3d opened this issue Jul 10, 2024 · 10 comments · Fixed by #1655
Closed
1 task done

feature: allow per task wait #1635

i3d opened this issue Jul 10, 2024 · 10 comments · Fixed by #1655
Labels
enhancement New feature or request

Comments

@i3d
Copy link

i3d commented Jul 10, 2024

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 i3d added the enhancement New feature or request label Jul 10, 2024
@i3d
Copy link
Author

i3d commented Jul 10, 2024

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
Copy link

Shougo commented Jul 11, 2024

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

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

The second concurrency option exists. It may work.

@i3d
Copy link
Author

i3d commented Jul 11, 2024

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
Copy link

Shougo commented Jul 11, 2024

Oh..

@folke
Copy link
Owner

folke commented Jul 14, 2024

I'll see to add something for this this evening

@mimikun
Copy link

mimikun commented Jul 16, 2024

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
Copy link
Owner

folke commented Jul 16, 2024

@mimikun what do you mean with previous behavior?

@mimikun
Copy link

mimikun commented Jul 16, 2024

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
Copy link

kdheepak commented Jul 16, 2024

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.

image

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
Copy link
Author

i3d commented Jul 16, 2024

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!!

folke pushed a commit that referenced this issue Jul 17, 2024
🤖 I have created a release *beep* *boop*
---


##
[11.12.0](v11.11.1...v11.12.0)
(2024-07-16)


### Features

* **git:** added git network throttle to limit network related git ops
per interval. Closes
[#1635](#1635)
([d731a6b](d731a6b))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
haunt98 added a commit to haunt98/dotfiles that referenced this issue Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants