At my company, we use pkg/errors to wrap our errors, giving them context and a stack trace. This has been a sore point when using the FDB Golang client as we initially thought we wouldn’t be able to wrap any errors within a Transact() call.
But, I recently realized that it seems all retryable errors are either returned by the Get() methods or by the transaction’s Commit() method. Is this statement true?
If it is true, then within a Transact() call, it should be safe to use the following rule: Always use the MustGet() method variant and wrap every error. This would work because all retryable errors would be communicated via a panic instead of a returned value.
I know little of Go, and therefore am not the right person to answer the rest of your question, but the Go bindings predate pkg/errors by a number of years, and thus it’s maybe unsurprising that they don’t play along together well. If you have suggested changes to the Go API to make it more modern-packages friendly, please put together a document to propose whatever design changes would improve the go bindings. (It’d probably be wise of us to adopt a CEP or KIP-like proposal process…)
Rather than a proposed change to the bindings, this is really asking about figuring out “best practices” for error wrapping within a call to Transact().
One thing to note is that panic’s are generally not considered idiomatic Go (there was a golang nuts thread about this a while ago where russ cox commented to this affect as well). I’d instead propose that the FDB golang bindings use errors.Is from Go 1.13.