[cristim]

Summary

• The Lambda adapter sent API JSON uncompressed, so GET /api/recommendations for a large tenant exceeds the 6 MB Function URL response limit (502 for all users). CloudFront compression only covers the edge-to-viewer hop.
• New compressLambdaResponse gzips JSON bodies of 64 KiB or more when the request accepts gzip and returns them base64-encoded with Content-Encoding: gzip and Vary: Accept-Encoding. Skipped for small, non-JSON, already-encoded or base64 responses and for clients without gzip. Wired into handleLambdaHTTPEvent for API responses only.
• This is the smallest change that removes the failure for realistic sizes without touching the frontend or the API contract. It raises the ceiling but does not bound it; pagination and slimmer rows are tracked in feat(recommendations): bound GET /api/recommendations with pagination and slimmer rows #777 (scoping found the dashboard and Opportunities page compute totals client-side over the full set, and details is only ~a quarter of a row, so those are larger changes).

Verification

• Unit tests: round-trip gunzip equals the original body, headers set, and each skip condition leaves the response untouched.
• Wiring test through the real handleLambdaHTTPEvent fails when the call in lambda.go is removed (status 401 body not encoded) and passes with it (threshold lowered for the test).
• go vet and go test ./internal/server pass on go1.26.9.
• Not verified: behaviour on a real Lambda Function URL behind CloudFront (no deploy); the compressed size of a real production payload. Reviewer should check that Function URLs accept a base64 gzip body with Content-Encoding set, as the repo already does for binary static files.

Refs #723

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 3 billable files and costs up to $0.75.}

• Ask an admin to make reviews automatic

Open in CodeRabbit

Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing.

Or wait 8 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available. Your 85 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: LeanerCloud/cloud-commitments-platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Essentials
• Run ID: 506f161d-928d-44c0-a89c-2c83f64898ec

---

📥 Commits

Reviewing files that changed from the base of the PR and between 225ad35 and c875dc9.

---

📒 Files selected for processing (3)

• internal/server/lambda.go
• internal/server/lambda_compress.go
• internal/server/lambda_compress_test.go

---

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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

[cristim]

Independent review (cc-cli-w2; I did not write this PR) at c875dc940de07e7f97f8b7fe0331c4aeb25b0a26, base 225ad350.

Verdict: CLEAN, no blocking findings. There are 3 non-blocking nits, and CI was still pending at the head when I checked.

What I checked:

• Wiring test fails before the fix. I removed the compressLambdaResponse(&request, resp) call from handleLambdaHTTPEvent (a -overlay mutation, the pre-fix wiring). TestHandleLambdaHTTPEvent_CompressesAPIJSONResponse then FAILS, and the two unit tests still pass. At the head, all 3 PR tests pass and go test ./internal/server passes in full (Go 1.26.9, -count=1, no -race).
• The test drives the real handler. The wiring test goes through the actual api.NewHandler path: an unauthenticated GET /api/recommendations returns a 401 JSON body, which is compressed only because the threshold is lowered to 1 byte.
• Other paths are unaffected.
  • OIDC (HandleOIDC) and static files (serveLambdaStatic) return before the new call.
  • API errors (err != nil) are returned untouched.
  • SQS and scheduled events never reach handleLambdaHTTPEvent.
• CloudFront and the Function URL. Production reaches the Function URL only through CloudFront: the origin access control signs every request, and default_cache_behavior sets compress = true with legacy forwarded_values (terraform/modules/frontend/aws/main.tf:60-92). AWS's documentation (Serve compressed files) says:
  • With compression on, CloudFront "includes the Accept-Encoding header in the cache key and in origin requests automatically", so the missing Accept-Encoding in the forwarded-headers list doesn't matter.
  • It strips values other than gzip/br. Brotli needs cache policies, so with legacy settings the origin sees gzip.
  • "When a response from an origin includes the Content-Encoding header, CloudFront doesn't compress the object, regardless of the header's value", so nothing is encoded twice.
  • The Function URL response format honours isBase64Encoded, the same mechanism serveLambdaStatic already uses for binary files.
• Header casing. isJSONResponse and acceptsGzip match keys case-insensitively. A probe with a lowercase content-type: application/json; charset=utf-8 compresses correctly.
• Size headroom. A probe on a 5.5 MB JSON array compressed to 166 KB after base64. My data is more repetitive than real rows, so treat that ratio as an upper bound on the benefit. Any ratio better than about 0.75 still keeps a body under 6 MB, because base64 adds 33%.

Non-blocking nits:

1. acceptsGzip treats gzip;q=0 as acceptance (a probe confirmed it compresses). RFC 9110 §12.5.3 says q=0 means "not acceptable". Browsers don't send that, and CloudFront normalizes the header, so the practical impact is nil. A one-line q-value check would make it exact.
2. Vary is written by overwriting the key as "Vary". A response that already had a lowercase vary: Origin would end up with both keys (a probe showed Vary:Accept-Encoding alongside vary:Origin). No API path sets Vary today (grep finds none), so this is latent. Appending case-insensitively would future-proof it.
3. application/problem+json and other +json types aren't compressed. The API emits none today, so this is informational.

Not verified: a real Lambda deploy, as the author also notes. A deployed check after merge would confirm a gzipped body on a large GET /api/recommendations through CloudFront.

[cristim]

Independent review: APPROVE at c875dc940de07e7f97f8b7fe0331c4aeb25b0a26

Reviewer: archera-quotes-codex. I did not write this PR. Base: 225ad350. Refs #723; pagination and slimmer rows are #777.

Behaviour, checked against source at this SHA:

• compressLambdaResponse runs only on the API branch of handleLambdaHTTPEvent. It does not run on statics (serveLambdaStatic returns earlier) or on an error return.
• It skips the response when any of these holds:
  • the response is nil or already base64;
  • the body is under 64 KiB;
  • the client does not accept gzip (case-insensitive header key);
  • the response is not application/json;
  • a Content-Encoding is already present, so nothing is encoded twice.
• A nil headers map has no content-type, so it is skipped before any write and cannot panic.
• The output is a standard-base64 gzip body with IsBase64Encoded=true and Content-Encoding: gzip. That is the same mechanism serveLambdaStatic already uses for binary bodies through the Function URL.
• Vary is set to Accept-Encoding. The API sets no Vary header today, so nothing is overwritten.

CloudFront (terraform/modules/frontend/aws/main.tf, default behavior):

• compress = true with legacy forwarded_values, and the header whitelist does not list Accept-Encoding.
• The AWS docs (Serving compressed files) say that when CloudFront is configured to compress, it includes the normalized Accept-Encoding in origin requests automatically. So the Lambda does see gzip behind CloudFront.
• An origin response that already has Content-Encoding is not compressed again.
• This is doc-based. There was no real deploy, which the body states honestly.

Reproduced (go1.26.9, GOWORK=off, -mod=readonly, no -race, source archive of this SHA):

• go vet ./internal/server is OK and go test ./internal/server passes. All 7 skip-condition subtests, the round-trip test and the wiring test pass.
• Mutants (go test -overlay). All are KILLED:
  • the wiring call removed from lambda.go: the wiring test fails, confirming the author's claim;
  • the accept-gzip check dropped;
  • the JSON check dropped;
  • the already-base64 check dropped;
  • the size threshold dropped;
  • the already-encoded (content-encoding) check dropped;
  • the Content-Encoding header not set;
  • IsBase64Encoded not set.

Nits (optional, P3):

• acceptsGzip treats Accept-Encoding: gzip;q=0 as accepting gzip. That is rare and harmless behind CloudFront, which normalizes the header.
• Vary overwrites rather than appends. That is fine today; if a future handler sets Vary: Origin, append instead.

Scope: this raises the 6 MB ceiling by roughly the gzip ratio (base64 adds about 33% back) but does not bound it. Refs rather than Closes, with #777, is the right call.

CI at this SHA: 23 SUCCESS, with Integration Tests in progress when I checked. The merge needs it green.

[cristim]

Merged (squash) at reviewed head c875dc9 -> 6f5a618. Reviewers: cc-cli-w2 (verdict on PR), archera-quotes-codex; both clean at this SHA. CI: 25/25 checks pass. Local: go build ./... exit 0; go test ./internal/server/... exit 0 (server, scheduledauth ok). Still owed: post-merge check on the deployed stack that a large /api/recommendations response comes back gzipped through CloudFront (not run by the merge operator).