Document upload moved to backend-issued presigned PUT URLs; Cognito Identity Pool removed
dropthejase replaced multipart upload through the Lambda with a three-step prepare/upload/register flow using presigned S3 PUT URLs generated by the backend. The browser uploads directly to S3 with no AWS credentials. Once that was in place, the Cognito Identity Pool had no remaining purpose and was removed entirely.
The new flow: POST /single-documents/prepare creates a DB row with status='processing', generates a presigned PutObject URL with a 15-minute TTL, and returns { docId, uploadKey, uploadUrl }. The browser PUTs the file directly to S3 via XHR - no SDK, no credentials. Then POST /single-documents/:documentId/register creates the document_versions row, sets current_version_id, and marks status='ready'. The Conversion Lambda fires via EventBridge on the S3 object creation event and handles DOCX-to-PDF in the background.
The same prepare/register split applies to project-scoped uploads at POST /projects/:projectId/documents/prepare and /:documentId/register. The multipart-through-Lambda path and handleDocumentUpload are removed.
Before this change, the frontend used Amplify uploadData with Identity Pool temporary credentials. After a brief intermediate state where both paths coexisted, 703ad3a deletes the AwsContext.tsx provider (87 lines that fetched and cached Identity Pool credentials), removes VITE_IDENTITY_POOL_ID from env examples, and strips the Cognito Identity Pool from AuthStack entirely. The authenticated IAM role retains GetObject/DeleteObject scoped to the user's prefix for potential future use.
The S3 path prefix changes too: the Identity Pool used ${cognito-identity.amazonaws.com:sub} (the identity ID, not the user pool sub). Presigned URL generation uses the user pool sub directly, since the API Lambda reads that from the validated JWT.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?