Fix: return 400 for invalid /base64 requests (AegisFlow 304cc0cbdc423fcf)

Tomiwa Adeyemirequested to merge
duo/fix/aegisflow-304cc0cbdc423fcf-1 into aegisflow-source

AegisFlow incident 304cc0cbdc423fcf

Related to #3 (closed)

Root cause

(*HTTPBin).Base64 in httpbin/handlers.go called panic(err) whenever newBase64Helper(...).transform() returned an error (introduced in 97d2d674). transform() returns ordinary client-input errors (invalid base64, input over the length limit, unknown operation), so bad requests to /base64/... caused a handler panic and HTTP 500 (Cloud Run revision aegisflow-app-fault-97d2d674, handler_panic, handlers.go:1165).

Changes

  • httpbin/handlers.go: replace panic(err) with writeError(w, http.StatusBadRequest, err) and return (general fix, no input special-casing).
  • New httpbin/aegisflow_regression_304cc0cbdc423fcf_test.go with TestAegisRegressionBase64ClientErrorsAreBadRequests (invalid input, unknown op, too long -> 400 + detail) and TestAegisRegressionBase64ValidRequestStillSucceeds.
  • No dependency, CI, policy, automation or security changes; no existing tests modified.

Test results

  • New tests FAIL on the base commit (panic / no 400) and PASS with the fix.
  • go test ./... and go vet ./... pass; scripts.policy_check (base ead6b277) passed.
  • Note: go test ./... requires GODEBUG=httpservecontentmaxranges=200 (as set in CI and Dockerfile.app); with the local default Go 1.27.3 environment, TestRange/ok_multiple_ranges fails independently of this change.
  • The MCP client could not fetch evidence in this runner (missing scoped controller read credential), so the diagnosis was verified by reproducing locally via TestBase64.

AegisFlow incident 304cc0cbdc423fcf Related to #3 (closed)

Merge request reports