eugenegujing opened a new issue, #7814: URL: https://github.com/apache/texera/issues/7814
### Task Summary `ResultExportService` turns a finished workflow's stored results into files for the user. Three of its methods have no test coverage anywhere in the repository: - `exportOperatorsAsZip` bundles several operators' results into one ZIP: it throws when the workflow has no execution (where the sibling `exportOperatorResultAsStream` returns `(null, None)`), dispatches each entry through the per-format writer on that operator's own `outputType`, wraps every entry in `NonClosingOutputStream` so one entry's writer cannot close the shared `ZipOutputStream`, and substitutes an `<id>-empty.txt` entry for an operator with no rows instead of aborting the archive. - `exportSingleOperatorToDataset` returns a per-operator error message rather than throwing, so one failure does not abort a multi-operator dataset export. - `getOperatorDocument` resolves the result URI and applies the `WarehouseReadGuard` read check from #6930. All three names occur only at their definitions and production call sites — within the 912-line `ResultExportServiceSpec` the reference counts are 0, 0 and 0. The multi-entry contract is the sharpest gap: `NonClosingOutputStream` is unit-tested in isolation, but nothing checks that the ZIP path actually routes entries through it, which is the failure the wrapper exists to prevent. This is an extension of the existing suite rather than a new one: the spec already runs on `MockTexeraDB` with seeded execution rows and already reads archives back with `ZipInputStream`. ### Task Type - [ ] Refactor / Cleanup - [ ] DevOps / Deployment / CI - [x] Testing / QA - [ ] Documentation - [ ] Performance - [ ] Other -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
