lakectl: share a single API client across a command invocation

[idanovo]

Change Description

Background

Every call to getClient() constructs a new apigen client, and each one gets its own http.Client with a cloned http.Transport — i.e. its own connection pool. Two places construct clients during a single lakectl run:

1. sendStats in PersistentPreRun (the usage-stats POST sent on every invocation), and
2. the command body itself (fs cat, fs download, etc.).

Because the two clients never share a pool, every lakectl invocation opens two TCP+TLS connections to the lakeFS server where one would do. For interactive use this is invisible; for fleets that spawn lakectl per work item it doubles the connection load on the server side. We observed this in production with a pipeline invoking lakectl ~1,500 times/second: the NLB in front of lakeFS recorded almost exactly 2 new flows per invocation, contributing to connection-tracking exhaustion on the hosts behind it. (Ironically, getHTTPClientWithRetryConfig already tunes MaxIdleConnsPerHost to avoid TIME_WAIT churn — a tuning that only pays off if callers actually share the transport.)

Bug Fix

1. Problem — each lakectl invocation dials the server twice (stats client + command client), doubling per-invocation connection cost.
2. Root cause — getClient() builds a new client + transport per call; the pre-run stats reporter and the command each call it once.
3. Solution — memoize the client with sync.Once (same pattern as getTokenOnce), renaming the constructor to newAPIClient(). All callers now share one client and one connection pool, so an invocation dials once. Config is finalized in preRunCmd before the first getClient() call, so construction inputs are identical to today's second call — no behavior change beyond connection reuse.

Testing Details

• go build ./cmd/lakectl/..., go vet ./cmd/lakectl/..., go test ./cmd/lakectl/... pass.
• TestMaybeWarnEnterprise switches the server endpoint between subtests; added a resetAPIClientCache() test helper and per-subtest reset so the memoized client follows the endpoint change.

Breaking Change?

No. Same requests, same auth, same User-Agent — just over one connection instead of two.

Additional info

For a process that makes a single API call (the most common CLI case: one command + one stats POST), this halves connections per invocation. It does not change the process-per-invocation cost itself — callers invoking lakectl once per file may still want to batch — but it makes the floor 1 connection instead of 2 for every lakectl user.

🤖 Generated with Claude Code