Same here. Yeah, it points to rather poor handling of error condition in this case, and it is an example of deeper problem of terrible error handling in Go, but overall - I don't see what the point is. There's plenty of worse code all over the place, in many programs, written in many languages, and this is hardly a notable offender.
to be sure in software one should know all possible inputs and outputs and why these happen. mentioned comment argues that this is not so for security service software. which is actually fun.
renewAuth() calls RenewTokenAsSelf() which calls ParseSecret() which calls DecodeJSONFromReader()
DecodeJSONFromReader has a couple of comments stating that the interface is a pointer along with "While decoding JSON values...", so is the reader an asynchronous object and renewal and renewal.Auth are modified after the error case is checked?