I'm not sure I understand the problem... When Gopkg.Toml specifies the version, and then we do dep ensure, this will put the correct specified version into the vendor dir, right? But then we also did go get in go-generate.sh which previously obtained the latest version, and that's the one we used to actually generate the library. Correct? And we didn't notice that before because go generate was executed in the wrong dir and didn't change anything.

When Gopkg.Toml specifies the version, and then we do dep ensure, this will put the correct specified version into the vendor dir, right?

yes

But then we also did go get in go-generate.sh which previously obtained the latest version, and that's the one we used to actually generate the library. Correct?

no, it checks out a specific version to build the msgp tool, which generates our messagepack code (when we run go generate), and that generated code uses the msgp library that is vendored, and thus should be at the same version.

And we didn't notice that before because go generate was executed in the wrong dir and didn't change anything.

yes

could we update go-generate.sh to read the revision number directly from Gopkg.lock and checkout out that commit?

I don't remember why right now, but there was a reason we didn't upgrade this last time. There is/was a breaking change when upgrading this library IIRC. I'll go try to find it.

@woodsaj that's a great idea! pushing that now.
@robert-milan i was also wondering if there's a specific reason we haven't updated yet, i imagine there is one but i also couldn't find it.

If no one can find the problem with the msgp library, can i get an approval on this?
Once I do, I'll update the schema dependency properly, which is currently causing the build failure.

for the record, deployed this to our internal ops env today using an in-place upgrade.
both during, as well as after the upgrade, everything stayed nominal.