Conversation
There was a problem hiding this comment.
This looks really great!
One thing that needs fixing -- the collection upload path looks broken. buildCollectionConfig() was removed from all five upload method components during the refactor but never wired back into PreparedUpload or submitPreparedUpload. CI confirms: both test_beta_upload_paste_links_as_list_collection and test_beta_upload_paste_links_as_paired_collection fail with AssertionError: 1.bed (gets individual datasets instead of a collection).
https://github.com/galaxyproject/galaxy/actions/runs/23252333865/job/67598826451
Fix should be straightforward: add a collectionConfig field to PreparedUpload, have each method's prepareUpload() include it when collection mode is active, and have submitPreparedUpload pass it through.
|
Woah! Good thing Marius added those tests, I completely overlooked that I was letting Copilot wipe the collection creation with the refactor, and I've been (I thought) carefully checking every change. I'm definitely working on integration tests next 😅 |
Addresses a regression where dataset collection configuration was not being correctly propagated through the upload pipeline. The collection configuration is now correctly captured from the upload method components and passed within the `PreparedUpload` object. This allows the upload submission logic to identify and utilize the collection configuration, ensuring that the appropriate API endpoint (`uploadCollectionDatasets`) is called for atomic collection creation.
Individual upload items that are part of a direct collection upload are now associated with this batch, which is then updated with the final collection ID upon success or an error message on failure.
Moves common upload state management (initialization, progress, status, error handling) into a new `uploadTracking` composable.
Extracts batch-specific operations, including collection creation, retry logic, and recovery mechanisms, into a new `useUploadBatchOperations` composable. This improves modularity and separates concerns from the main `useUploadQueue`.
Removes the `useUploadQueue` composable and centralizes its responsibilities within `useUploadSubmission` and `useUploadBatchOperations`. This refactoring provides clearer separation of concerns and streamlines the upload process: - Item-level validation moves to `uploadItemTypes.ts`. - Batch-specific operations, including a new `processDirectBatch` for atomic collection creation via `/api/tools/fetch`, are now handled by `useUploadBatchOperations`. - `useUploadSubmission` now orchestrates the entire upload flow, clearly distinguishing between direct collection creation and two-step collection creation (for items like data library copies that require individual processing).
Introduces shared upload fixtures to keep tests consistent and easier to extend. Expands coverage for item validation, direct collection submission, and two-step collection creation so library-only and mixed uploads behave reliably. Verifies retry and recovery paths after interrupted or failed collection creation, helping prevent silent post-upload errors.
|
There are some more consolidating and refactoring changes, but collections should be working now. I'll start working next on integration tests for #21878 |
2 participants
Resolves #21877
This PR adds a new
useUploadMethodModalcomposable that lets you configure and open the new upload dialog used in the Tool and Workflow Forms.Also includes refactorings to unify handling of upload items, both in the activity panel and the dialog, as well as some type improvements.
The new dialog is accessible as an alternative option to the existing upload dialog until it gets fully replaced after the deprecation period.
Workflow Run Form
Data Dialog
See it in action
UploadDialog.mp4
How to test the changes?
(Select all options that apply)
License