cooperspencer / gickup

https://cooperspencer.github.io/gickup-documentation/
Apache License 2.0
955 stars 33 forks source link

Retry Requests #153

Closed mtoohey31 closed 1 year ago

mtoohey31 commented 1 year ago

A couple times over the past few months, the gickup systemd service that I run has failed with an error message such as the following:

2023-05-31T14:00:10-04:00 FTL Get "https://api.github.com/user": net/http: TLS handshake timeout stage=github url=https://github.com

This seems to be a relatively harmless intermittent network failure, but it causes gickup to stop and exit. It would be nice if we could retry requests caused by these types of failures so that intermittent network issues don't cause gickup to exit.

I took a quick look, and it doesn't look like github.com/shurcooL/githubv4 has any way of configuring retries. A quick-and-dirty solution might be to attempt to error.As returned err values into the net.Error type and check the return value of its Timeout() method, then retry a couple times with exponential backoff as long as it returns true.

cooperspencer commented 1 year ago

Thanks for pointing that out, I haven't noticed yet. It actually depends on which module the problem originates from, because I use two different modules:

The workaround you described is probably the best option to solve this issue.

cooperspencer commented 1 year ago

What version are you using? Because in the current version, there is no Fatal in the Github part.

mtoohey31 commented 1 year ago

Ah sorry, should've mentioned that, I'm running 0.10.13.

cooperspencer commented 1 year ago

Can you please try a newer version? From 0.10.14 on it doesn't immediately die because of every little thing. We can still try to implement a retry option with a short wait time if needed.

mtoohey31 commented 1 year ago

I tried upgrading @cooperspencer, but I'm using the Nix package manager, and it needs to be able to build the program using vendored Go modules so it can ensure that everything is reproducible, but I can't get gickup to build like that right now:

$ go mod vendor
$ go build
# golang.org/x/sys/unix
vendor/golang.org/x/sys/unix/syscall.go:83:16: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_linux.go:2271:9: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_unix.go:118:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/sysvshm_unix.go:33:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)

This is gickup v0.10.16 with go version go1.20.2 linux/amd64. I believe you either need to increment the go 1.16 declaration in go.mod to go 1.17 then run go mod tidy, or downgrade the transitive dependency on golang.org/x/sys/unix so that it doesn't use unsafe.Slice. I'm honestly not sure why the build only fails with vendored modules though...

I've opened a PR at #156 to implement the first solution. Feel free to close it though if you'd prefer the second option.

cooperspencer commented 1 year ago

I just merged your changes and created a new release with it.

mtoohey31 commented 1 year ago

Thanks, v0.10.17 builds for me! I'm running that version now, and I'll let you know if I run into any issues. I probably should've mentioned in the original post: I don't get this error very frequently (it's happened only about 8 times since January), so I won't know for sure if it's fixed for a while. So I'm going to close the issue for now; if it happens again on a newer version though I'll reopen it then.