mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-10 23:15:40 +00:00
xarmian
157ca4e88f
* chore: bump Go toolchain to 1.26 (TASK-763) Bump Go from 1.25 to 1.26 across all toolchain pins: - go.mod — go 1.25.0 → go 1.26.0 - Dockerfile — golang:1.25-alpine → golang:1.26-alpine - .github/workflows/ci.yml — three setup-go steps (Go, Go-Postgres, E2E jobs) - .github/workflows/release.yml — release pipeline No `toolchain` directive: the repo is pre-launch with no external contributors yet, so we set the floor where we want it (hard requirement). Verified locally before commit: - golangci-lint v2.11.4 builds and runs under Go 1.26.2 (pinned in CI) - golang:1.26-alpine and 1.26.2-alpine images present on Docker Hub - go build ./... clean - go vet ./... clean - go test ./... all pass Parent: PLAN-644 (OSS Repo Hygiene and Launch Polish). * chore: gofmt -w under Go 1.26 (TASK-763) Apply Go 1.26's gofmt to the codebase. ~41 files reformatted, all struct-tag whitespace realignment — no semantic changes. Verified: - gofmt -l ./cmd ./internal returns empty after - go build ./... still clean - go test ./... still passes (run before commit) Bundling the gofmt diff with the toolchain bump in the same PR because the formatting drift is a direct consequence of moving from 1.25 to 1.26; splitting them creates a mandatory two-PR ordering for no value. Parent: PLAN-644. * docs: bump documented Go floor to 1.26 (TASK-763) Match go.mod's hard 1.26.0 requirement in the source-build instructions. Caught by Codex review round 1 on PR #247. - README.md:158 — "Go 1.25+" → "Go 1.26+" - CONTRIBUTING.md:9 — "Go 1.25+" → "Go 1.26+"
63 lines
2.1 KiB
Go
63 lines
2.1 KiB
Go
package server
|
|
|
|
import (
|
|
"bytes"
|
|
"net/http/httptest"
|
|
"strings"
|
|
"testing"
|
|
)
|
|
|
|
// TestDecodeJSON_RejectsOversizeBody ensures the default 2 MiB cap is
|
|
// enforced — without http.MaxBytesReader a multi-GB POST would stream
|
|
// into a single allocation and could OOM the process.
|
|
func TestDecodeJSON_RejectsOversizeBody(t *testing.T) {
|
|
// 3 MiB of harmless but oversize JSON.
|
|
body := []byte(`{"x":"` + strings.Repeat("a", 3<<20) + `"}`)
|
|
req := httptest.NewRequest("POST", "/", bytes.NewReader(body))
|
|
req.Header.Set("Content-Type", "application/json")
|
|
|
|
var target map[string]any
|
|
err := decodeJSON(req, &target)
|
|
if err == nil {
|
|
t.Fatalf("expected oversize body to be rejected, got nil error")
|
|
}
|
|
if !strings.Contains(err.Error(), "request body too large") &&
|
|
!strings.Contains(err.Error(), "http: request body too large") {
|
|
// MaxBytesReader wraps the "request body too large" error into the
|
|
// json.Decoder failure, which bubbles up through the invalid-JSON
|
|
// wrap. Just verify SOME error surfaced — the exact wording is
|
|
// tied to stdlib internals.
|
|
t.Logf("got error: %v", err)
|
|
}
|
|
}
|
|
|
|
// TestDecodeJSON_AcceptsWithinLimit confirms the happy path still works.
|
|
func TestDecodeJSON_AcceptsWithinLimit(t *testing.T) {
|
|
req := httptest.NewRequest("POST", "/", bytes.NewReader([]byte(`{"name":"ok"}`)))
|
|
req.Header.Set("Content-Type", "application/json")
|
|
|
|
var target struct {
|
|
Name string `json:"name"`
|
|
}
|
|
if err := decodeJSON(req, &target); err != nil {
|
|
t.Fatalf("unexpected error: %v", err)
|
|
}
|
|
if target.Name != "ok" {
|
|
t.Fatalf("got name=%q, want %q", target.Name, "ok")
|
|
}
|
|
}
|
|
|
|
// TestDecodeJSONWithLimit_CustomCap verifies callers can opt in to a
|
|
// larger cap (for bulk-import style endpoints).
|
|
func TestDecodeJSONWithLimit_CustomCap(t *testing.T) {
|
|
// 1 MiB body; below default 2 MiB but above our custom 256 KiB cap.
|
|
body := []byte(`{"x":"` + strings.Repeat("a", 1<<20) + `"}`)
|
|
req := httptest.NewRequest("POST", "/", bytes.NewReader(body))
|
|
req.Header.Set("Content-Type", "application/json")
|
|
|
|
var target map[string]any
|
|
if err := decodeJSONWithLimit(req, &target, 256<<10); err == nil {
|
|
t.Fatal("expected 256 KiB cap to reject 1 MiB body, got nil")
|
|
}
|
|
}
|