Skip to content

[gax] Set max_body_size on DecompressResponse for Tesla 1.21 compatibility - #1

Open
smn wants to merge 2 commits into
mainfrom
tesla-1.21-max-body-size
Open

[gax] Set max_body_size on DecompressResponse for Tesla 1.21 compatibility#1
smn wants to merge 2 commits into
mainfrom
tesla-1.21-max-body-size

Conversation

@smn

@smn smn commented Aug 19, 2026

Copy link
Copy Markdown

Why

Tesla 1.21 made :max_body_size a required option on Tesla.Middleware.Compression / DecompressResponse (a decompression-bomb CVE fix, no global-config or opt-out). GoogleApi.Gax.Connection's __using__ macro hardcodes plug(Tesla.Middleware.DecompressResponse, []), so every generated GoogleApi.*.Connection raises ArgumentError at request time under Tesla 1.21+.

Upstream googleapis/elixir-google-api was archived (2026-06-30) — reportedly because of this exact Tesla change — so no upstream fix will land. This is a minimal fork patch so turnhub/engage can upgrade to Tesla 1.21.1.

Changes

  • clients/gax: plug(Tesla.Middleware.DecompressResponse, max_body_size: :infinity):infinity preserves the pre-1.21 behaviour (no cap), which is appropriate for these trusted Google endpoints that legitimately return large payloads.
  • clients/gax/mix.exs: loosen :mime to ~> 1.0 or ~> 2.0 so it resolves alongside modern deps (engage is on mime 2.0.7).

Note

Temporary. turnhub/engage will migrate off elixir-google-api to Req + Goth; this fork can be retired once that lands.

Tesla 1.21 made :max_body_size mandatory on the compression middleware (a
decompression-bomb CVE fix). Upstream elixir-google-api was archived before
adopting it, so pin :infinity to preserve pre-1.21 behaviour and unblock the
Tesla upgrade in turnhub/engage. Temporary until we migrate off this library.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@admindehaan
admindehaan requested a review from benonymus August 19, 2026 14:55
benonymus
benonymus previously approved these changes Aug 20, 2026
@smn

smn commented Aug 20, 2026

Copy link
Copy Markdown
Author

leaving this open as the mix.exs in engage references it, I hope this is the only fix we need while we work our way off of the Google libs.

Tesla 1.21 validates multipart field names with
assert_quoted_string_safe!/2, which only accepts binaries. build_body/3
passed the :metadata atom and keyword-list body/file param keys straight
through, so every multipart upload (e.g. GCS
storage_objects_insert_simple) crashed with FunctionClauseError. The
wire format is unchanged: atoms were already interpolated into the
Content-Disposition name before.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants