david-navapbc

I've refactored `HttpClientUtils.getDefaultHttpClient` to return a singleton instead of a new instance. I've also refactored `invoke()` to include an "also" call to close the client after use. The ticket speaks...

I **think** I've run to ground all non-test references to HttpClientUtils. As far as I can tell literally none of them are being created with an httpClient object and thus...

I don't know why but `server2server` smoke tests are failing in this branch only. Things are working properly in `master`. Somehow turning the httpclient in HttpClientUtils has either broken that...

not fixed yet. here's where things are at: * I verified that the same smoke tests are failing in the ci/cd pipeline so it's not a local issue * I've...

I have a working theory. Inside the default client creation method is a check to see if the caller has supplied an auth argument. If they have, the auth argument...

Refactor complete. Functionally here's what's up * if the caller requests the default client sans auth (as in - doesn't pass an auth token) they get the httpClient singleton. *...

made all updates as per reviewer request. awaiting final approval

refactored things to not use `use{...}` and instead put the `close()` blocks back in. tl'dr - something about `use{...}` breaks our ability to reuse the client object. see this for...

the reason the original PR was passing, as was the latest iteration where "close" appeared to be working - is due to a bug. Props to @arnejduranovic for finding it....

**_tl'dr_** the closest we're going to come to a singleton client object that frees resources after each request is to change the ktor engine we're using from apache4 to apache5...