aws-sdk-go timeouts

[guywithnose]

What version of Go (go version) and dep (git describe --tags) are you using?

1.8
v0.1.0-215-g911cd22

What dep command did you run?

dep init -v

What did you expect to see?

aws-sdk-go@v1.8.11

What did you see instead?

aws-sdk-go@v1.10.8

This happens when a git command takes more than 2 minutes to complete. While it is a legitimate timeout error, the problem is that instead of retrying the correct version it moves on to the next. Since this was an error on the fetch command, I wouldn't have expected it to advance versions.

The timeout is set to 2 minutes, but on conference wifi time git clone https://github.com/aws/aws-sdk-go takes over 11 minutes.
https://github.com/golang/dep/blob/master/internal/gps/cmd.go#L145

[DDRBoxman]

I also ran into this at the convention this morning. Running dep init on my project at home ended up with different results in the Gopkg.lock file.

[sdboyer]

yeah, we really gotta get a better handle on failures like these. it seems like our check-for-progress mechanism should prevent them from happening - the git commands should be cut off after a little while. but the bigger answer here is that we need to improve observability of the fs and network interactions in the tool overall.

[DDRBoxman]

I ran into a similar issue today with a repo that uses git LFS to store about 600MB of files. Looks like dep is downloading all those files too.

[sdboyer]

ugh, git-lfs is kinda concerning from a verification (#121) perspective, as it seems like those files being conditionally populated is...not great.

assuming i'm understanding it correctly, anyway - it's a git extension that just transparently changes the behavior to not download these large files? if that's accurate, it seems like having the extension installed should be sufficient for dep to do the right thing, as the docs https://git-lfs.github.com/ seem to suggest it fits transparently into your workflow.

[DDRBoxman]

Yeah, if you have the extension installed it just works. It may just take longer than dep wants to wait around for, heh.

[sdboyer]

dep doesn't actually use a timeout - rather, we use a "progress checker." as long as the process is making progress (as indicated by activity on stderr/stdout), it will generally let it continue running. so a simple timeout shouldn't be what's going on.

unfortunately, our lack of observability instrumentation down at that layer makes it hard to say for sure 😢 😢