fix(plugin-import-export): incorrect user type in Export causing runtime type mismatch#14790
Merged
JarrodMFlesch merged 4 commits intoDec 2, 2025
Merged
Conversation
Contributor
📦 esbuild Bundle Analysis for payloadThis analysis was generated by esbuild-bundle-analyzer. 🤖 |
JarrodMFlesch
previously approved these changes
Dec 2, 2025
JarrodMFlesch
approved these changes
Dec 2, 2025
JarrodMFlesch
deleted the
fix/plugin-import-export-user-type-consistency
branch
Contributor
|
🚀 This is included in version v3.66.0 |
zubricks
pushed a commit
that referenced
this pull request
Jan 6, 2026
…ime type mismatch (#14790) ### What? Separated user serialization concerns from runtime user handling in the export plugin by moving `user` and `userCollection` fields out of the base `Export` type into a new `ExportJobInput` type, and using a separate `user` parameter in `CreateExportArgs`. ### Why? The `Export` type had `user: string` which was meant for job queue serialization, but when exports ran directly (without job queue), the full user object was being passed where a string was expected. This created a type mismatch that only worked by accident at runtime. ### How? - Removed `user` and `userCollection` from base `Export` type - Created `ExportJobInput` type that extends `Export` with serialization fields - Updated `CreateExportArgs` to accept `user?: TypedUser | null` as separate parameter - Fixed all call sites to pass user separately instead of in input object - Added validation to ensure user exists before creating exports - Job queue handler now strips serialization fields before passing to `createExport`
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
2 participants
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?
Separated user serialization concerns from runtime user handling in the export plugin by moving
useranduserCollectionfields out of the baseExporttype into a newExportJobInputtype, and using a separateuserparameter inCreateExportArgs.Why?
The
Exporttype haduser: stringwhich was meant for job queue serialization, but when exports ran directly (without job queue), the full user object was being passed where a string was expected. This created a type mismatch that only worked by accident at runtime.How?
useranduserCollectionfrom baseExporttypeExportJobInputtype that extendsExportwith serialization fieldsCreateExportArgsto acceptuser?: TypedUser | nullas separate parametercreateExport