Does go get command seem stuck?

Goal

How to unstuck your go get command

Description

Last week I had an issue with golang in my computer. I executed go mod vendor in one of the projects I was working on and while downloading one of the dependencies, the system would be stuck without the ability to download.

I thought that it could be an issue with that particular library or a version that I was referring to, so I started to investigate…

How to

In this recipe, I’ll guide you through the investigation and how I fixed the issue. Notice that I spent a little too much on that day trying to spot an issue from the outside, i.e., with that particular dependency/library but, in the end, the issue was in my machine, not something external!

After ensuring nothing was wrong externally, by checking it with other colleagues that were able to successfully download the dependency, I started checking the versions of both golang and git that were on my machine. Since they were a bit older, I tried to update them but, still, no good.

I needed to understand what was happening and as such, I started going a bit deeper into the command and the library download that was being performed under the hood, As such, I tried to download different versions of the library through command go get directly, and by passing in the flag -x to see more debugging information, like so:

$> go get -x
somegitlab.com/group1/group2/myliblib@v1.18.0

And in the output I saw a lot of non interesting stuff such as resolving the paths to the library in gitlab, but also something a bit stranger locally around the path of /Users/paulo.zenida/work/go/pkg/mod/cache/vcs, namely some messages around locks in a full path similar to: lock /Users/paulo.zenida/work/go/pkg/mod/cache/vcs/b98979fc4e08ef592bed097a3c8646f8ca994ae03de7537097d25953c7ab578d.lock.

Could it be an issue with the cache and some locking? It seemed promising so, I took my chances and cleaned up the cache from go mod with the following command:

$> rm -rf
/Users/paulo.zenida/work/go/pkg/mod/cache

and retesting the original command of go mod. Eureka!!! That was it. It worked.

notifier.Get().Register(&obs{})
}

func init() {
Init()
}

type obs struct{}

func (o *obs) OnNotify(e *obspattern.Event) {
e.Data = append(e.Data, doStuff())
}

func doStuff() string {
return “OBSERVER2: additional data”
}

Finally, here’s the main.go file with the setup of the example code:

package main

import (
	"fmt"

	"notifier"

	_ "observer1" // register the observer through its init method
	_ "observer2" // register the observer through its init method
	"obspattern"
)

func main() {
	n := notifier.Get()

	evt := obspattern.Event{
		Data: []string{"Initial Data"},
	}
	n.Notify(&evt)

	for _, d := range evt.Data {
		fmt.Println(d)
	}
}

The previous is a simple way to configure the observers to be listening for the events sent by the subject/notifier. If, however, you need more control over the order of the observers (one that the order of the imports does not guarantee, for example), you could do the following instead:

package main

import (
	"fmt"

	"notifier"

	"observer1"
	"observer2"
	"obspattern"
)

func init() {
	observer2.Init()
	observer1.Init()
}

func main() {
	n := notifier.Get()

	evt := obspattern.Event{
		Data: []string{"Initial Data"},
	}
	n.Notify(&evt)

	for _, d := range evt.Data {
		fmt.Println(d)
	}
}

Explanation

Although not sure why it happened, it seems that my golang mod directly got stuck with some lock and as such, it was unable to perform its job of downloading dependencies.

If you ever find yourself in such situation, deleting your local mod cache directory as explained in this recipe might be useful.