New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
httpcli: make caching transport unwrappable #49877
Conversation
Codenotify: Notifying subscribers in CODENOTIFY files for diff 4c1785b...67dea8e.
|
internal/extsvc/crates/client.go
Outdated
func NewClient(urn string, httpfactory *httpcli.Factory) *Client { | ||
uncached, _ := httpfactory.Doer(httpcli.NewCachedTransportOpt(httpcli.NoopCache{}, false)) | ||
func NewClient(urn string, httpfactory *httpcli.Factory) (*Client, error) { | ||
time.Sleep(time.Second * 30) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
loool
cli.Transport = &wrappedTransport{ | ||
RoundTripper: &httpcache.Transport{ | ||
Transport: cli.Transport, | ||
Cache: c, | ||
MarkCachedResponses: markCachedResponses, | ||
}, | ||
Wrapped: cli.Transport, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea if this is sane, do you happen to know why this helps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've checked, all this concept is used for is to be able to set values on the base *http.Transport like here: https://sourcegraph.com/github.com/sourcegraph/sourcegraph@nsc/htticli-wrapped-cacher/-/blob/internal/httpcli/client.go?L683
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im thinking it worked before because of some sort of ordering assumption cc @bobheadxi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct on being able to set values, and ordering changes could definitely make it mess up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feels fragile, is it much work to not be order dependent? 👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC the middleware works in a chain - each one modifies the client then passes it on to the next. There seems to be 4 middleware that depend on access to the underlying transport (calling getTransportForMutation
), maybe we could make it so that they are a special kind of middleware that is applied first, before anyone has had a chance to wrap the transport? It could make the interface a bit clunkier though
Alternatively, we add some more documentation asking that implementers always use wrappedTransport
if they want to change the transport type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
definitely rather fragile though, maybe we can have a test that runs through the default external/internal transport setups?
For some reason, we had panics in production because caching transport wasnt unwrappable. Being unwrappable seems benign, so we'll implement it for that
Test plan
Ran locally, no more panic