fs/fshttp: fix TestCertificates leaking client cert/key onto global config - #9843
Conversation
ncw
left a comment
There was a problem hiding this comment.
Thanks for fixing this up
I thought of a neater way of doing this - see inline
| @@ -177,6 +177,14 @@ func TestCertificates(t *testing.T) { | |||
There was a problem hiding this comment.
I think a better fix would be to to use fs.AddConfig here which makes a private config just for this test.
PS No need for a massive comment :-)
8a75eda to
b7e6c41
Compare
|
Thanks - // Use a private config so the cert paths don't leak into other tests
ctx, ci := fs.AddConfig(context.TODO())Verified the leak is actually fixed rather than just moved: a throwaway test placed after |
557491c to
ffb10d0
Compare
…onfig This was fixed in this commit in an inelegant way 399bc6a fshttp: don't send --header values to other hosts on redirect The current commit fixes it properly with AddConfig. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
ffb10d0 to
5960e69
Compare
Split out from the discussion in #9841, per @ncw's request there.
TestCertificatessetsci.ClientCert/ci.ClientKeyon the process-globalConfigInfo(the test'sctxcarries no override) to a path undert.TempDir(), and never resets them. Go removest.TempDir()on test cleanup, so any later test infs/fshttpthat builds a client viaNewTransportCustomfails trying to load a cert file that no longer exists.Harmless on its own -- it only surfaces once something else in the same test binary calls
NewClient/NewTransportCustomafterTestCertificatesruns, sincego testexecutes tests within a package in source order by default. I hit it while adding a new test to this package for #9841.One-line fix: reset both fields in a
defer, same pattern used elsewhere in this file.