Skip to content

Conversation

@sosweetham
Copy link
Member

@sosweetham sosweetham commented Jan 28, 2026

Description of change

fixes file upload error message on esigner

Issue Number

closes #713

Type of change

  • Fix (a change which fixes an issue)

How the change has been tested

manual

Change checklist

  • I have ensured that the CI Checks pass locally
  • I have removed any unnecessary logic
  • My code is well documented
  • I have signed my commits
  • My code follows the pattern of the application
  • I have self reviewed my code

Summary by CodeRabbit

  • Bug Fixes

    • Added client-side 20MB file-size validation with clearer, targeted error messages for oversized uploads
    • Improved upload error handling to distinguish client-side and server-side file-size violations
  • Chores

    • Standardized server-side limits to 20MB (request body parsing and upload handling)

✏️ Tip: You can customize this high-level summary in your review settings.

@sosweetham sosweetham requested a review from coodos as a code owner January 28, 2026 08:28
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 28, 2026

Warning

Rate limit exceeded

@sosweetham has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 2 minutes and 8 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

Reduced server and client upload limits to 20MB, added client-side file size validation with a FileSizeError class, improved upload error handling to map HTTP 413 responses into FileSizeError, and updated the upload page to present clearer size-related error messages.

Changes

Cohort / File(s) Summary
API body parser
platforms/esigner-api/src/index.ts
Reduced express.json and express.urlencoded body parser limits from 50mb to 20mb.
Multer upload config
platforms/esigner-api/src/controllers/FileController.ts
Increased multer max file size from 10MB to 20MB (server-side upload limit adjusted).
File store (client)
platforms/esigner/src/lib/stores/files.ts
Added MAX_FILE_SIZE = 20MB and exported FileSizeError; pre-upload size validation that throws FileSizeError; enhanced catch to detect HTTP 413 and construct a server-informed FileSizeError (updates error store and rethrows).
Upload UI
platforms/esigner/src/routes/(protected)/files/new/+page.svelte
Imported FileSizeError, updated upload error handling to show specific file-size messages for FileSizeError and a generic retry message for other errors.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant Browser
    participant Store as File Store
    participant API as Backend API

    User->>Browser: Select file & trigger upload
    Browser->>Store: uploadFile(file)
    Store->>Store: Compare file.size to MAX_FILE_SIZE (20MB)
    alt Exceeds client limit
        Store->>Browser: Throw FileSizeError (client-side)
        Browser->>User: Display size violation message
    else Within client limit
        Store->>API: POST file (multipart/form-data)
        API->>API: Multer enforces 20MB limit
        alt Exceeds server limit
            API-->>Store: HTTP 413 Payload Too Large
            Store->>Store: Build FileSizeError from server data
            Store->>Browser: Throw FileSizeError
            Browser->>User: Display server-provided size error
        else Upload success
            API-->>Store: 200 OK
            Store->>Browser: Refresh file list
            Browser->>User: File available for signing
        end
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

  • coodos
  • Bekiboo

Poem

🐰 I hopped and checked each file with care,
Twenty megs now fits—no silent despair.
Errors now tell the tale so clear,
Uploads and users both cheer! 🥕✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: implementing file upload error handling improvements for eSigner, which aligns with the core objective of the PR.
Description check ✅ Passed The description follows the template structure with all required sections completed: issue number, type of change, testing method, and all checklist items marked as done.
Linked Issues check ✅ Passed The PR successfully addresses issue #713 by increasing the file size limit to 20MB and implementing clear error messaging for file size violations, meeting both expected behaviors outlined in the issue.
Out of Scope Changes check ✅ Passed All code changes are directly related to the file upload size limit and error handling objectives in issue #713; no extraneous modifications were introduced.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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


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

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🤖 Fix all issues with AI agents
In `@platforms/esigner-api/src/controllers/FileController.ts`:
- Around line 5-8: The current multer setup buffers uploads in memory (const
upload = multer(..., storage: multer.memoryStorage())) with a 1GB limit which
risks exhausting process memory under concurrent uploads; change to a safer
approach by replacing multer.memoryStorage() with multer.diskStorage() and
stream writes to the final destination in the upload handling code (or add
per-user quota and concurrency controls around the upload middleware), or if
intentional add a clear comment above the upload declaration documenting the
risk and listing mitigating infrastructure (load‑balancer limits, container
memory limits) and/or implement upload concurrency limits around the upload
middleware; refer to the upload constant and the use of multer.memoryStorage()
when making the change.

In `@platforms/esigner-api/src/index.ts`:
- Around line 64-65: The body-parser limits are set to an excessively large 1gb
via express.json(...) and express.urlencoded(...), which risks memory
exhaustion; lower these limits to a reasonable size (e.g., 10-50MB) by updating
the express.json and express.urlencoded calls in index.ts to a smaller limit and
leave multer’s file-size limits to handle multipart uploads (adjust multer
configuration separately if larger file uploads are required). Ensure you change
the limit values referenced in the express.json and express.urlencoded calls and
verify multer remains responsible for multipart/form-data file size enforcement.

In `@platforms/esigner/src/routes/`(protected)/files/new/+page.svelte:
- Line 5: The import line currently brings in unused symbols `files` and
`fetchFiles`; remove those two from the import so only `uploadFile` and
`FileSizeError` are imported (i.e., change the import that references `files,
fetchFiles, uploadFile, FileSizeError` to import just `uploadFile` and
`FileSizeError`) to eliminate dead imports and related lint warnings.
🧹 Nitpick comments (1)
platforms/esigner/src/lib/stores/files.ts (1)

105-120: HTTP 413 handling looks correct, but type assertion could be cleaner.

The error handling correctly detects 413 responses and extracts server-provided size information. However, using axios's built-in types would be more robust.

Optional: Use axios types for cleaner error handling
-	} catch (err: unknown) {
-		// Handle HTTP 413 Payload Too Large
-		if (err && typeof err === 'object' && 'response' in err) {
-			const axiosError = err as { response?: { status?: number; data?: { error?: string; maxSize?: number; fileSize?: number } } };
-			if (axiosError.response?.status === 413) {
+	} catch (err: unknown) {
+		// Handle HTTP 413 Payload Too Large
+		import { isAxiosError } from 'axios';
+		if (isAxiosError(err) && err.response?.status === 413) {
+			const data = err.response.data as { error?: string; maxSize?: number; fileSize?: number } | undefined;

Note: isAxiosError would need to be imported at the top of the file.

Comment on lines 5 to 8
const upload = multer({
limits: { fileSize: 10 * 1024 * 1024 }, // 10MB limit
limits: { fileSize: 1024 * 1024 * 1024 }, // 1GB limit
storage: multer.memoryStorage(),
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Memory storage with 1GB limit poses a resource exhaustion risk.

Using multer.memoryStorage() with a 1GB limit means entire files are buffered in memory. Concurrent uploads of large files could exhaust server memory and crash the process.

Consider one of these alternatives for production:

  1. Use disk storage (multer.diskStorage()) and stream to the final destination
  2. Implement upload size quotas per user
  3. Add concurrency limits on uploads

If this tradeoff is intentional for simplicity, consider adding a comment documenting the risk and any mitigating infrastructure (e.g., load balancer limits, container memory limits).

🤖 Prompt for AI Agents
In `@platforms/esigner-api/src/controllers/FileController.ts` around lines 5 - 8,
The current multer setup buffers uploads in memory (const upload = multer(...,
storage: multer.memoryStorage())) with a 1GB limit which risks exhausting
process memory under concurrent uploads; change to a safer approach by replacing
multer.memoryStorage() with multer.diskStorage() and stream writes to the final
destination in the upload handling code (or add per-user quota and concurrency
controls around the upload middleware), or if intentional add a clear comment
above the upload declaration documenting the risk and listing mitigating
infrastructure (load‑balancer limits, container memory limits) and/or implement
upload concurrency limits around the upload middleware; refer to the upload
constant and the use of multer.memoryStorage() when making the change.

import { goto } from '$app/navigation';
import { isAuthenticated } from '$lib/stores/auth';
import { uploadFile } from '$lib/stores/files';
import { files, fetchFiles, uploadFile, FileSizeError } from '$lib/stores/files';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

rg -n '\b(files|fetchFiles)\b' 'platforms/esigner/src/routes/(protected)/files/new/+page.svelte' | grep -v 'import'

Repository: MetaState-Prototype-Project/prototype

Length of output: 1067


Remove unused imports files and fetchFiles.

The imports files and fetchFiles are not used in this file. Only uploadFile and FileSizeError are referenced. Remove the unused imports from line 5.

🤖 Prompt for AI Agents
In `@platforms/esigner/src/routes/`(protected)/files/new/+page.svelte at line 5,
The import line currently brings in unused symbols `files` and `fetchFiles`;
remove those two from the import so only `uploadFile` and `FileSizeError` are
imported (i.e., change the import that references `files, fetchFiles,
uploadFile, FileSizeError` to import just `uploadFile` and `FileSizeError`) to
eliminate dead imports and related lint warnings.

@sosweetham sosweetham changed the title fix(e-signer): file upload error handling and coherent limits with file manager fix(e-signer): file upload error handling Jan 28, 2026
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@platforms/esigner-api/src/controllers/FileController.ts`:
- Around line 5-7: Add a global error-handling middleware after all routes to
catch multer file-size errors: detect errors that are instances of MulterError
(or have error.code === 'LIMIT_FILE_SIZE') produced by the upload middleware
(the upload constant using multer.memoryStorage()), and respond with HTTP 413
and a clear message; non-multer errors should be passed to the next handler or
handled normally. Ensure the middleware is registered after route registration
so LIMIT_FILE_SIZE errors thrown during middleware preprocessing are converted
to 413 responses.

@coodos coodos merged commit 24811ba into main Jan 28, 2026
4 checks passed
@coodos coodos deleted the fix/coherent-file-manager-esigner-limits branch January 28, 2026 09:01
coodos pushed a commit that referenced this pull request Jan 30, 2026
* fix(e-signer): file upload error handling and coherent limits with file manager

* fix: readd svelte markup

* fix: coderabbit suggestions

* fix: limit to 20 megs

* fix: express req body size 20M
@coderabbitai coderabbitai bot mentioned this pull request Jan 30, 2026
6 tasks
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.

[Bug] Files ≥1024 KB cannot be used for signing in eSigner and user isn't informed crearly about limit

3 participants