fix(plugin-cloud-storage): clear stale uploadEdits before metadata persistence update - #17848
Open
AlgoArtist06 wants to merge 1 commit into
Conversation
…rsistence update The afterChange hook's nested req.payload.update reuses the original req, which still carries req.query.uploadEdits from the first request. generateFileData re-reads those edits and re-enters the file re-processing path, re-cropping the already-cropped file on every crop upload, which fails with a BadRequestError or FileRetrievalError. Clear uploadEdits alongside req.file and req.payloadUploadSizes so the metadata persistence update stays data-only. Fixes payloadcms#15991
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
When a document is saved with a crop (or any resize/focal-point edit) via the
@payloadcms/plugin-cloud-storageplugin, the whole upload fails.The plugin's
afterChangehook uploads the file to the adapter and then persists the adapter's returned metadata through a nestedreq.payload.update()that reuses the originalreq. Before that call it clearsreq.fileandreq.payloadUploadSizesto prevent re-processing, but it leavesreq.query.uploadEditsintact.Payload's
generateFileDatareadsuploadEditsstraight fromreq.queryon every update and returnstruefromshouldReupload()whenever a crop/resize/focal change is present. So the metadata-persistence update re-enters the full file re-processing path and re-crops the already-cropped file. On recent versions this surfaces as an HTTP 400 (BadRequestError: There was a problem while uploading the file/extract_area: bad extract area); on older versions it fails with aFileRetrievalErrorwhile trying to re-fetch the just-created file by URL.Why?
The
uploadEditsinreq.querydescribe the edits applied to the original file. They have already been consumed by the first pass ofgenerateFileDatabefore the hook runs, so they must not be re-applied to the already-processed file by the plugin's internal metadata update. The leak turns a supposedly data-only metadata persistence call into a second image edit.How?
In
getAfterChangeHook, alongside the existingreq.file = undefined/req.payloadUploadSizes = undefinedcleanup, drop the already-consumeduploadEditsfromreq.querybefore the nestedreq.payload.update(). This matches the suggested fix from the issue and keeps the metadata persistence data-only.Added a focused integration regression test (
test/plugin-cloud-storage/crop-repro.int.spec.ts) that creates a crop-edited upload through the plugin with an in-memory adapter and asserts the document persists successfully with the adapter metadata. The test boots a lightweight config that needs no Docker/localstack and reproduces the failure without the fix.Fixes #15991
Automated by pr-pipeline (com.ashutosh.prpipeline).