Bug: async Promise executor in makeZipFile may prevent proper error propagation #39118
Description
Description:
The implementation of makeZipFile in:
apps/meteor/server/lib/dataExport/makeZipFile.ts
uses the pattern:
new Promise(async (resolve, reject) => { ... })
Using an async function as a Promise executor is considered an anti-pattern. If any awaited operation inside the executor (such as archive.finalize()) throws or rejects, the outer Promise may not properly propagate the error.
This can potentially cause export/compression flows to hang instead of rejecting cleanly, making failure scenarios harder to detect and handle.
Steps to reproduce:
- Trigger a data export that invokes
makeZipFile. - Simulate or force
archive.finalize()to throw or reject. - Observe that the export flow may not properly reject and could remain pending.
Expected behavior:
If archive.finalize() or any internal async operation fails, the Promise returned by makeZipFile should reject properly so that the caller can handle the error.
Actual behavior:
Due to the use of new Promise(async ...), rejections inside the async executor may not propagate correctly, potentially leaving the outer Promise unresolved and causing export flows to hang.
Server Setup Information:
- Version of Rocket.Chat Server: Any
- License Type: Any
- Number of Users: Any
- Operating System: Any
- Deployment Method: Any
- Number of Running Instances: Any
- DB Replicaset Oplog: Any
- NodeJS Version: Any
- MongoDB Version: Any
Client Setup Information
- Desktop App or Browser Version: Any
- Operating System: Any
Additional context
Using async as a Promise executor is discouraged because thrown errors are not automatically wired to the outer Promise’s reject handler.
Refactoring the implementation to avoid an async executor ensures correct error propagation and prevents potential export hangs without changing business logic.
Relevant logs:
Not applicable. This is a control-flow and async error propagation issue observable through code inspection and runtime behavior.