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

"unexpected EOF during skip" error #1196

Closed
NobodyXu opened this issue Jul 10, 2023 · 6 comments · Fixed by #1201 or #1203
Closed

"unexpected EOF during skip" error #1196

NobodyXu opened this issue Jul 10, 2023 · 6 comments · Fixed by #1201 or #1203

Comments

@NobodyXu
Copy link
Member

I keep getting:

+ cargo binstall --no-confirm [email protected]
 INFO resolve: Resolving package: 'cargo-watch@=8.4.0'
ERROR Fatal error:
  × For crate cargo-watch: I/O Error: unexpected EOF during skip
  ╰─▶ I/O Error: unexpected EOF during skip

when merging, they sometimes happen so I'm not sure whether it's a bug or just network failure.

Originally posted by @NobodyXu in #1186 (comment)

@NobodyXu
Copy link
Member Author

This is spurious but annoying

@NobodyXu
Copy link
Member Author

Ok so this actually comes from tar.

I was thinking about switching from tokio-tar back to it in #1200, but now it looks like a bad idea.
It will probably still fail just different errors, although it's better to return errors gracefully than panic.

@NobodyXu
Copy link
Member Author

Both this issue and #1200 arises after I tried to speed the CI up by #1186 and #1188, so maybe we are sending http requests so fast that it is hitting the rate limit again.

@passcod Perhaps it is a good idea to apply more harsh rate limit in our binary?
Our default 10/1 (1 request each 10ms), changing it to 20/1 or 30/1 might fix the errors.

@passcod
Copy link
Member

passcod commented Jul 12, 2023

Can we set a harsher rate limit for CI only? We're going to have much stronger use than most consumers, it doesn't make sense to penalise the users for an issue that apparently only we're hitting.

NobodyXu added a commit that referenced this issue Jul 13, 2023
and set `BINSTALL_RATE_LIMIT` to `50/1` on CI.

Fixed #1196

Signed-off-by: Jiahao XU <[email protected]>
@NobodyXu
Copy link
Member Author

Can we set a harsher rate limit for CI only? We're going to have much stronger use than most consumers, it doesn't make sense to penalise the users for an issue that apparently only we're hitting.

I've opened #1201 and applied the harsh rate limit for CI only.

NobodyXu added a commit that referenced this issue Jul 13, 2023
and set `BINSTALL_RATE_LIMIT` to `100/1` on CI.

Fixed #1196

Signed-off-by: Jiahao XU <[email protected]>
NobodyXu added a commit that referenced this issue Jul 14, 2023
NobodyXu added a commit that referenced this issue Jul 16, 2023
NobodyXu added a commit that referenced this issue Jul 16, 2023
NobodyXu added a commit that referenced this issue Jul 17, 2023
and set `BINSTALL_RATE_LIMIT` to `100/1` on CI.

Fixed #1196

Signed-off-by: Jiahao XU <[email protected]>
NobodyXu added a commit that referenced this issue Jul 17, 2023
#1201)

feat: Scrap `--rate-limit` from env `BINSTALL_RATE_LIMIT` as a fallback

and set `BINSTALL_RATE_LIMIT` to `100/1` on CI.

Fixed #1196

Signed-off-by: Jiahao XU <[email protected]>
@NobodyXu
Copy link
Member Author

Just realize that tokio-tar also has this "unexpected EOF during skip" error.

Fortunately tokio-tar v0.3.1 is out, let's try it out and see if it would fix the panic and this error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants