Add implementation for Request GetBody to handle connections gracefully

[amooabeebadesina]

Based on this incident: https://buffer.slack.com/archives/C0KS2S8D7/p1770237580910489

This PR allows to set the GetBody function on the request object. This is then passed as an http client to the elastic search sdk to use.

Summary by CodeRabbit

• New Features

  • Improved retry behavior for signed HTTPS requests, adding HTTP/2-compatible request retries and a custom HTTP client to ensure bodies are replayed for reliable retries.

• Chores

  • Initialized module and dependency declarations, adding required libraries for AWS signing, MongoDB and Elasticsearch integrations to support the new client behavior.

[coderabbitai]

Walkthrough

Adds a retryableTransport in elasticsearch/elasticsearch.go that captures and reuses request bodies (using GetBody when absent) to enable HTTP/2 request retries, creates a custom HTTP client with that transport, and passes it into the AWS signing client for HTTPS requests in non-LOCAL environments. Updates imports to support body replication and transport customization. Adds go.mod declaring module github.com/bufferapp/go-base-worker, Go 1.19, and required dependencies.

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly relates to the main change: implementing Request.GetBody to handle HTTP/2 request retries and connections. It accurately summarizes the primary modification across the changeset.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In `@elasticsearch/elasticsearch.go`:
- Around line 3-9: The outbound HTTP calls to Elasticsearch use http.Client
without a timeout which can hang; update the code that constructs the
http.Client used for Elasticsearch requests (the client used in the
Elasticsearch request logic) to set a sensible Timeout (e.g.,
http.Client{Timeout: 10 * time.Second}), add import "time", and/or use
context.WithTimeout when creating request contexts to ensure requests fail fast
and goroutines don't hang; apply the same change to any other http.Client
instances used for outbound calls in this file.
- Around line 22-28: In retryableTransport.RoundTrip, if io.ReadAll(req.Body)
returns an error you must close req.Body to avoid leaking the underlying reader;
update the error path in RoundTrip to call req.Body.Close() before returning the
error and ensure any later replacement of req.Body (when creating GetBody or
resetting) still uses a fresh io.NopCloser wrapping the captured bytes (refer to
req.Body and req.GetBody in retryableTransport.RoundTrip).

In `@go.mod`:
- Around line 1-3: Update the Go version in go.mod to a supported release by
changing the go directive from "go 1.19" to a currently supported version (e.g.,
"go 1.23" or "go 1.24"); edit the go.mod file's go directive so the module
declaration (module github.com/bufferapp/go-base-worker) stays the same but the
go X.Y line reflects the chosen supported version and then run `go mod tidy` /
rebuild to verify compatibility.

🧹 Nitpick comments (1)

elasticsearch/elasticsearch.go (1)

22-35: Guard against unbounded buffering of large request bodies.

io.ReadAll will load the entire body into memory; for large bulk requests this can spike memory or OOM. Consider only buffering when size is known and below a cap.

🧩 Suggested approach

+const maxRetryBodyBytes int64 = 4 << 20 // 4 MiB
+
 func (t *retryableTransport) RoundTrip(req *http.Request) (*http.Response, error) {
 	// If body exists and GetBody is not set, capture the body for retries
-	if req.Body != nil && req.GetBody == nil {
+	if req.Body != nil && req.GetBody == nil &&
+		req.ContentLength >= 0 && req.ContentLength <= maxRetryBodyBytes {
 		bodyBytes, err := io.ReadAll(req.Body)
 		if err != nil {
 			return nil, err
 		}
 		req.Body.Close()

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Go 1.19 end of life support dates currently supported versions 2025

💡 Result:

Go 1.19 end-of-life (upstream Go toolchain)

• Go 1.19 released: 2022-08-02.
• Support policy: each major Go release is supported until there are two newer major releases. [1]
• Since Go 1.21 released on 2023-08-08, Go 1.19 fell out of support at that point under the policy. [1]
• The last Go 1.19 patch release was go1.19.13 (2023-09-06), and EOL trackers list Go 1.19 support as ending 2023-09-06. [1][3]

“Currently supported” Go versions (what this meant during 2025)

Go security fixes are prepared for the two most recent major releases. [2]

In calendar year 2025, that changed mid-year:

• From 2025-02-11 (Go 1.24) until 2025-08-12 (Go 1.25): supported majors were Go 1.24 and Go 1.23. [1][3]
• From 2025-08-12 onward: supported majors were Go 1.25 and Go 1.24. [1][3]

Sources: [1] Go release history & release policy (go.dev) • [2] Go security policy (go.dev) • [3] Go version support/EOL table (endoflife.date)

---

Upgrade to a supported Go version.

Go 1.19 reached end-of-life on 2023-09-06 and no longer receives security updates. Currently, only Go 1.23 and Go 1.24 receive security patches. Upgrade to one of these versions.

🤖 Prompt for AI Agents

In `@go.mod` around lines 1 - 3, Update the Go version in go.mod to a supported
release by changing the go directive from "go 1.19" to a currently supported
version (e.g., "go 1.23" or "go 1.24"); edit the go.mod file's go directive so
the module declaration (module github.com/bufferapp/go-base-worker) stays the
same but the go X.Y line reflects the chosen supported version and then run `go
mod tidy` / rebuild to verify compatibility.