fix: backup memory usage

[lpiepiora]

What type of PR is this?

• bug

What this PR does / why we need it:

This PR creates a separate setting for memory to use when importing backups. Currently the upload limit is used for memory settings for ParseMultipartForm, which is not ideal for running in constrained environments.

Which issue(s) this PR fixes:

Fixes #1581

Testing

I have tested the change with the manually uploading my export of 1.2GB on a system that previously crashed with OOME.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 1437f732-4e9d-43b8-83dd-37345ebe116b

📥 Commits

Reviewing files that changed from the base of the PR and between 75a8d9e and 70dbfa0.

📒 Files selected for processing (4)

• backend/app/api/handlers/v1/controller.go
• backend/app/api/handlers/v1/v1_ctrl_exports.go
• backend/app/api/routes.go
• backend/internal/sys/config/conf.go

🚧 Files skipped from review as they are similar to previous changes (4)

• backend/app/api/handlers/v1/controller.go
• backend/app/api/routes.go
• backend/internal/sys/config/conf.go
• backend/app/api/handlers/v1/v1_ctrl_exports.go

---

Summary by CodeRabbit

• New Features
  • Added a new configuration option to control the memory limit used when parsing multipart import uploads.
• Bug Fixes
  • Import uploads now respect the new multipart parsing memory threshold (improving handling of larger uploads).
• Documentation / Configuration
  • Updated the import size limit setting to use the max_import_size configuration key (replacing the previous name).

Walkthrough

Adds a new max_parse_memory web config, wires it into V1Controller, and uses it for multipart parsing during collection imports. The import size YAML key is renamed to max_import_size.

Changes

Multipart import parse memory

Layer / File(s)	Summary
Web config fields backend/internal/sys/config/conf.go	WebConfig adds MaxParseMemory with max_parse_memory/64 MB, and MaxImportSize now uses max_import_size.
Controller option and state backend/app/api/handlers/v1/controller.go	V1Controller gains maxParseMemory and a WithMaxParseMemory option that stores it.
Route wiring and multipart parsing backend/app/api/routes.go, backend/app/api/handlers/v1/v1_ctrl_exports.go	Route mounting passes a.conf.Web.MaxParseMemory, and collection import parsing uses ctrl.maxParseMemory << 20 for ParseMultipartForm.

Security recommendation: keep max_parse_memory deployment-configured and bounded so multipart parsing stays under expected memory limits.

Sequence Diagram(s)

sequenceDiagram
  participant Routes as backend/app/api/routes.go
  participant V1Controller
  participant HandleCollectionImport
  participant ParseMultipartForm as r.ParseMultipartForm

  Routes->>V1Controller: v1.WithMaxParseMemory(a.conf.Web.MaxParseMemory)
  V1Controller->>V1Controller: store ctrl.maxParseMemory
  HandleCollectionImport->>ParseMultipartForm: ParseMultipartForm(ctrl.maxParseMemory << 20)

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

A backup zip came knocking late,
With memory trimmed to a gentler state.
The parser nodded, took the hint,
And spooled its load without a flint.
✨

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	⚠️ Warning	The YAML key rename from max_import_upload to max_import_size is unrelated to the memory-usage fix.	Keep the config-schema rename in a separate PR or explain it in the issue; otherwise limit this PR to the new parse-memory setting and wiring.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately reflects the main change: separating backup import memory usage.
Description check	✅ Passed	The PR description covers the required template sections and includes the issue reference and testing notes.
Linked Issues check	✅ Passed	The change separates multipart parse memory from upload size and matches the backup-import OOME fix in #1581.

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

✨ Finishing Touches

✨ Simplify code

• Create PR with simplified code

---

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.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

backend/internal/sys/config/conf.go (1)

100-102: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Fix the typos in the new field's doc comment.

Two small grammar slips: "the data that does not fit" should drop the leading "the", and "spil" should be "spill".

📝 Proposed wording

-	// MaxParseMemory is the amount of memory used when parsing multipart form
-	// the data that does not fit into this memory will spil to temp files.
-	// Defaults to 64 MB.
+	// MaxParseMemory is the amount of memory (in MB) used when parsing a
+	// multipart form; data that does not fit into this memory will spill to
+	// temp files. Defaults to 64 MB.

🤖 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 `@backend/internal/sys/config/conf.go` around lines 100 - 102, The new
MaxParseMemory doc comment in conf.go has two wording typos that should be
corrected: remove the extra leading “the” from the phrase describing data that
does not fit in memory, and change “spil” to “spill.” Update the comment
attached to MaxParseMemory so the grammar is clean and consistent with the
surrounding documentation.

🤖 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 `@backend/app/api/handlers/v1/v1_ctrl_exports.go`:
- Around line 230-233: Update the multipart upload comment near
ParseMultipartForm in v1_ctrl_exports.go to reflect the actual behavior:
maxParseMemory is only the memory-vs-disk threshold for ParseMultipartForm,
while the total request size limit is enforced separately by the path-aware
middleware. Keep the note aligned with the multipart handling logic in the
export handler so the comment does not imply ParseMultipartForm is enforcing the
whole-body cap.

---

Nitpick comments:
In `@backend/internal/sys/config/conf.go`:
- Around line 100-102: The new MaxParseMemory doc comment in conf.go has two
wording typos that should be corrected: remove the extra leading “the” from the
phrase describing data that does not fit in memory, and change “spil” to
“spill.” Update the comment attached to MaxParseMemory so the grammar is clean
and consistent with the surrounding documentation.

🪄 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: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: c2153155-eb89-41a0-890c-7961f6996aae

📥 Commits

Reviewing files that changed from the base of the PR and between 1701e60 and 75a8d9e.

📒 Files selected for processing (4)

• backend/app/api/handlers/v1/controller.go
• backend/app/api/handlers/v1/v1_ctrl_exports.go
• backend/app/api/routes.go
• backend/internal/sys/config/conf.go