fix(storage): handleClientUpload throwing errors

[designcode]

Note

Low Risk
Low risk: changes are limited to error handling/wrapping in storage upload helpers and add a small shared toError utility; main behavior change is returning structured errors instead of throwing.

Overview
Prevents server-side upload helpers from throwing by normalizing unknown exceptions into Error responses.

Adds shared toError and uses it in handleClientUpload, put, and initMultipartUpload to wrap/catch failures (including adding more descriptive multipart-init errors), so callers consistently receive { error: Error } rather than uncaught exceptions.

^{Written by Cursor Bugbot for commit 9474601. This will update automatically on new commits. Configure here.}

[greptile-apps]

Greptile Summary

This PR adds defensive error handling to handleClientUpload and initMultipartUpload to prevent unhandled exceptions from escaping these functions. Instead of letting S3 SDK errors propagate as thrown exceptions, both functions now catch them and return the standard { error } result shape expected by callers.

Changes:

• server.ts: Wraps the entire switch block in handleClientUpload in a try/catch, converting any unexpected throw into a { error } return value.
• multipart.ts: Wraps the tigrisClient.send() call in initMultipartUpload with a try/catch for the same reason.

Minor issues found:

• Both catch blocks use const { message } = error as { message: string }, which is unsafe if the thrown value is null (destructuring from null throws a TypeError inside the catch block itself). Using error instanceof Error ? error.message : ... is safer.
• In multipart.ts, if a non-Error value is thrown, message will be undefined, resulting in the misleading string "Unable to initialize multipart upload: undefined".

Confidence Score: 4/5

Safe to merge — the error handling fix is correct for the common case; the unsafe destructuring is a low-likelihood edge case with the AWS SDK.

The core fix is sound and addresses the stated problem. The only remaining issues are P2 style concerns around the unsafe error as { message: string } destructuring pattern in both catch blocks, which could theoretically throw inside a catch block if null is thrown — very unlikely with the AWS SDK but worth hardening.

Both changed files share the same unsafe error destructuring pattern in their catch blocks.

Important Files Changed

Filename	Overview
packages/storage/src/lib/object/multipart.ts	Wraps the tigrisClient.send() call in initMultipartUpload in a try-catch to prevent unhandled promise rejections from propagating; minor unsafe error destructuring in the catch block.
packages/storage/src/lib/upload/server.ts	Wraps the entire handleClientUpload switch in a try-catch as a defensive outer safety net; same unsafe error as { message: string } destructuring pattern in the catch block.

_{Reviews (1): Last reviewed commit: "fix(storage): handleClientUpload throwin..." | Re-trigger Greptile}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[github-actions]

🎉 This PR is included in version 2.15.6 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 1.4.1 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀