fix: Download of binary DICOM and study index writes wrong files#127
Open
wayfarer3130 wants to merge 4 commits into
Open
fix: Download of binary DICOM and study index writes wrong files#127wayfarer3130 wants to merge 4 commits into
wayfarer3130 wants to merge 4 commits into
Conversation
…er bun - Declare <studyUIDs...> as a required positional on the studies command so commander reports a missing-argument error instead of exiting silently (previously the variadic -d option could swallow the study UID, leaving the command with no arguments and studiesMain returned without a message). - Import uids via its subpath in static-wado-creator index.mjs; mixing an ESM import of the static-wado-util package root with the CJS require() calls elsewhere in the package made bun treat the root as an async module and fail with "require() async module is unsupported". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
On upload, fileToKey strips "/index.json.gz" so the study singleton index is stored at the S3 key "studies/<uid>". On retrieve, contentItemToFileName had no reverse mapping for that key shape and fell through to "studies/<uid>.gz", so the study index never landed at studies/<uid>/index.json.gz and mkdicomweb index could not add the study to the overall studies index. dir() now detects directory-style index objects generically: any listed key that also has child keys maps back to <key>/index.json.gz. This covers the study singleton, the overall studies index, and instance-level query indexes, without hardcoding path names. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
fileToKey strips the .mht extension on upload, so multipart objects live at extension-less keys (frames/1, bulkdata/xx/yy/zzzz). The directory listing can only guess "<key>.gz" for those, which stored retrieved frames as 1.gz instead of 1.mht / 1.mht.gz. - S3Ops.retrieve now corrects the destination name from the object's ContentType/ContentEncoding: multipart/related objects are written as <key>.mht, or <key>.mht.gz when gzip encoded. - S3Ops.localCandidates lists the possible local names for a listed object so DeployGroup.retrieve can recognize already-retrieved .mht files and skip re-downloading them. - DeployGroup renames files stored under the generic ".gz" name by older retrieves to their correct multipart name, sniffing the leading bytes (multipart boundary, or gzip whose content starts with a boundary) so gzipped JSON like metadata.gz is left alone. Skipped on --dry-run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
The download of full studies from S3 fails because it doesn't download the correct names for a variety of files, including the study index and binary segmentation part 10 files.
As well, the index re-creation also fails due to mixed import/require options.