Difficulty updating submodule versions

[pcriv]

I'm currently on version v0.23.1

When I try to update I get the following output:

❯ go get -u github.com/riverqueue/river
go: upgraded github.com/riverqueue/river v0.23.1 => v0.25.0
go: upgraded github.com/riverqueue/river/riverdriver v0.23.1 => v0.25.0
go: upgraded github.com/riverqueue/river/riverdriver/riverpgxv5 v0.23.1 => v0.25.0
go: upgraded github.com/riverqueue/river/rivershared v0.23.1 => v0.25.0
go: upgraded github.com/riverqueue/river/rivertype v0.23.1 => v0.25.0
go: upgraded github.com/tidwall/match v1.1.1 => v1.2.0
go: upgraded golang.org/x/mod v0.27.0 => v0.28.0

After when I run go mod tidy

❯ go mod tidy
go: finding module for package github.com/riverqueue/river/internal/util/dbutil
go: github.com/riverqueue/river/cmd/river imports
        github.com/riverqueue/river/cmd/river/rivercli imports
        github.com/riverqueue/river/riverdriver/riversqlite imports
        github.com/riverqueue/river/internal/util/dbutil: module github.com/riverqueue/river@latest found (v0.25.0), but does not contain package github.com/riverqueue/river/internal/util/dbutil
make: *** [tidy] Error 1

Any ideas how to solve it?

[pcriv]

Okay, I think I've solved it, issue was related to having the river cmd installed as a tool and not updated. Updating it on the indirect dependencies did the trick

[bgentry]

Ugh, we've seen this issue pop up a few times in different ways. It seems to be something related to Go modules and local caching, even though as far as we can tell we have all our modules set up correctly. 😞 Often we'll do the upgrades with the most nested dep first like go get github.com/riverqueue/river/riverdriver/[email protected] and that seems to have a higher success rate at getting related deps upgraded.

@brandur do you think there's anything we should do on the documentation side here, either the website or go docs or both? 🤔

[brandur]

So the only reliable way I know for sure to do this is just to make sure to include every package you're using all in the same invocation. Here's a line from the pro make update target for example:

	go get -u github.com/riverqueue/river@$(RIVER_BRANCH) \
		github.com/riverqueue/river/riverdriver@$(RIVER_BRANCH) \
		github.com/riverqueue/river/riverdriver/riverdatabasesql@$(RIVER_BRANCH) \
		github.com/riverqueue/river/riverdriver/riverpgxv5@$(RIVER_BRANCH) \
		github.com/riverqueue/river/riverdriver/riversqlite@$(RIVER_BRANCH) \
		github.com/riverqueue/river/rivershared@$(RIVER_BRANCH) \
		github.com/riverqueue/river/rivertype@$(RIVER_BRANCH) && \
	go mod tidy

The problem is that it's a bit tricky to know exactly which drivers everyone's using. You could try to parse it out of go.mod with a grep or something, but that's a bit bleh.

I guess we might be able to include every module and then also just make sure to have a go mod tidy after any sample invocations like that. If the go get was successful the go mod tidy should remove any unused drivers from go.mod, so you'll end up wasting a bit of work fetching something unnecessary, but at least it'll go away reasonably quickly.

Thoughts on that approach?

[bgentry]

That approach should work. I'm also wondering if this is an annoying enough problem to justify adding a CLI command for it. Especially for Pro customers, there are just a lot of submodules to align and keep in sync.