feat: added MAPLE_MAX_PAYLOAD_SIZE env var to avoid 413 error

[skrafft]

There's a default body limit to 2MB in axum which was not configurable. This PR aims to be able to configure this default limit with an env variable.

---

Summary by CodeRabbit

• New Features
  • Added configurable maximum request payload size limit with a 2MB default
  • Maximum payload size can be customized via environment variable configuration
  • Application now enforces request body size constraints

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds a configurable maximum request payload size to the Maple Proxy application. A new configuration constant and field allow users to set the limit via the MAPLE_MAX_PAYLOAD_SIZE environment variable, with a default of 2 MB. The router applies this limit through Axum's DefaultBodyLimit layer.

Changes

Maximum Payload Size Configuration

Layer / File(s)	Summary
Configuration constant and payload size field src/config.rs	Added DEFAULT_MAX_PAYLOAD_SIZE constant and max_payload_size field to Config struct, parsed from MAPLE_MAX_PAYLOAD_SIZE environment variable with clap, initialized to the default constant in Config::new().
Router body limit enforcement src/lib.rs	Imported axum::extract::DefaultBodyLimit and applied DefaultBodyLimit::max(config.max_payload_size) as a router layer to enforce the configured maximum request body size.

🎯 2 (Simple) | ⏱️ ~8 minutes

🐰 A payload limit we now can set,
Two megs by default, no need to fret,
Through config it flows to Axum's hand,
Requests too large just won't land!

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: adding a MAPLE_MAX_PAYLOAD_SIZE environment variable to make the request body limit configurable and avoid 413 errors.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/config.rs (1)

172-224: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Add CLI parsing tests for max_payload_size default and 0 handling

• src/config.rs currently tests only the timeout CLI args; add coverage that parsing ["maple-proxy"] sets max_payload_size to DEFAULT_MAX_PAYLOAD_SIZE.
• max_payload_size uses clap::value_parser!(usize) with no .range(1..), so --max-payload-size 0 is not inherently invalid—either update the test to expect it parses, or add a range(1..) constraint and then assert ErrorKind::ValueValidation for 0.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/config.rs` around lines 172 - 224, Add CLI parsing tests and validate
max_payload_size input: update the clap parser for the Config field that uses
clap::value_parser!(usize) (the max_payload_size field) to require a positive
value by adding .range(1..) to the value parser, then add tests similar to the
timeout tests that assert Config::try_parse_from(["maple-proxy"]) yields
max_payload_size == DEFAULT_MAX_PAYLOAD_SIZE and
Config::try_parse_from(["maple-proxy", "--max-payload-size",
"0"]).unwrap_err().kind() == ErrorKind::ValueValidation; this ensures default
behavior is tested and a zero value is rejected.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/config.rs`:
- Around line 60-65: The MAPLE_MAX_PAYLOAD_SIZE clap argument currently uses
clap::value_parser!(usize) which allows 0; update the arg on the struct field
that references DEFAULT_MAX_PAYLOAD_SIZE to enforce a lower bound by applying a
range (e.g. .range(1..)) on the value parser so parses below 1 fail at CLI parse
time, and add a focused config-parser unit test that asserts that "0" is
rejected and "1" (or DEFAULT_MAX_PAYLOAD_SIZE) is accepted; look for the arg
attribute block containing MAPLE_MAX_PAYLOAD_SIZE and DEFAULT_MAX_PAYLOAD_SIZE
to implement this change and the corresponding test.

---

Outside diff comments:
In `@src/config.rs`:
- Around line 172-224: Add CLI parsing tests and validate max_payload_size
input: update the clap parser for the Config field that uses
clap::value_parser!(usize) (the max_payload_size field) to require a positive
value by adding .range(1..) to the value parser, then add tests similar to the
timeout tests that assert Config::try_parse_from(["maple-proxy"]) yields
max_payload_size == DEFAULT_MAX_PAYLOAD_SIZE and
Config::try_parse_from(["maple-proxy", "--max-payload-size",
"0"]).unwrap_err().kind() == ErrorKind::ValueValidation; this ensures default
behavior is tested and a zero value is rejected.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f34e9d01-7663-44fc-83fc-d923da2049a8

📥 Commits

Reviewing files that changed from the base of the PR and between 41cf9f2 and 7a60c22.

📒 Files selected for processing (2)

• src/config.rs
• src/lib.rs

[devin-ai-integration]

Devin Review found 1 potential issue.

View 3 additional findings in Devin Review.

[AnthonyRonning]

Have you tested this and has it resolved your issue?

[skrafft]

Yes I tested it, my issue is solved (I tried with multiple > 2MB requests)