Max retry time exceeded – Octokit.js connection pool exhaustion

When integrating Octokit.js to call GitHub's REST API, developers occasionally observe the log message “Max retry time exceeded” during periods of high request volume. The goal is to determine whether this symptom originates from client‑side connection pool exhaustion caused by OS file‑descriptor limits or from retaining stale connections after transient 502/503 responses from api.github.com. Relevant constraints include distinguishing the symptom from genuine rate‑limit responses (HTTP 429 with X‑RateLimit‑Remaining: 0), accounting for keep‑alive behavior and the Connection: close header, and ensuring that local testing does not artificially constrain outbound ports.

Which configuration or diagnostic approach most reliably isolates the root cause of the “Max retry time exceeded” error?

Does enabling TCP keep‑alive and honoring the Connection: close header reduce CLOSE_WAIT accumulation that leads to pool exhaustion?

Is the error correlated with reaching the process file‑descriptor limit as reported by ulimit -n, independent of GitHub’s transient 5xx responses?