Could you provide some sample code and stack trace output after panics? It would help a lot with this issue, thanks!

Sorry, I was a bit unclear, I'm actually trying to implement the interface defined in net/http.

I also realized that it doesn't accept context either, which means if your cookie jar makes calls to external services (ie redis, a sql database), these become untrackable in tracing and uncancelable if they take a long time. Ideally the interface would be changed to be more like this:

type CookieJar interface {
	// SetCookies handles the receipt of the cookies in a reply for the
	// given URL.  It may or may not choose to save the cookies, depending
	// on the jar's policy and implementation.
	SetCookies(c context.Context, u *url.URL, cookies []*Cookie) error

	// Cookies returns the cookies to send in a request for the given URL.
	// It is up to the implementation to honor the standard cookie use
	// restrictions such as in RFC 6265.
	Cookies(c context.Context, u *url.URL) ([]*Cookie, error)
}

Hopefully this is more clear. I also see that this was an issue during intial development since if the official implementation of cookiejar encounters an error it just silently returns no cookies: https://github.com/golang/go/blob/master/src/net/http/cookiejar/jar.go#L167

This is probably not ideal since if you're relying on the cookiejar to handle auth to an API, you would probably want the request to be canceled with an error that the caller can handle rather than continuing the request with no cookies.

This seems like a request for a change to the standard library, and might need a proposal of some sort. We can't break existing code by changing interfaces that they might call or implement.
@neild @rsc

As @dr2chase says, we can't change the CookieJar interface.

Working within the constraints of the current interface, I can imagine having a paired RoundTripper wrapper and CookieJar implementation, where RoundTrip sets the jar's context before proceeding and checks its error status upon completion. This would be pretty clumsy, but probably could be made to work.

An updated CookieJar API that accepts a context.Context and returns an error doesn't seem unreasonable, but it'd need some thought into what the exact API should be and how to integrate it into the existing net/http APIs without backwards compatibility issues, as well as a proposal.

🤔 Ignoring the existing CookieJar interface and just implementing a RoundTripper does seem like a good idea within the confines of the existing interface.

As for updating the interface so that its actually consumable rather than just being ignored, my thought was to make a CookieJarV2 interface and field in Client that if specified takes precedence over regular CookieJar. Behavior would be that if a "non nil" CookieJarV2 were given, to use that always. If a "nil" value is given to the Client, then to fall back to old CookieJar and the default of both being nil means cookies are only sent if they are explicitly set on the Request.

This should give full backward compatibility. Docs would just mark old CookieJar as deprecated and sometime during golang 2.0 it can be removed entirely. Its kinda ugly IMO and maybe confusing, but the behavior of unaware code shouldn't change.