- Shipped
- August 6, 2026 at 7:04 PM UTC
- Author
- Kamo
- Commit
- 8db077c
Object storage is bucket-per-association (every reader resolves img.getAssocId().getBucket()), but deduplication is scoped ORG-wide or GLOBALly and so crosses associations. registerExistingDocument attached an existing ImgDat to a brand-new association without uploading any bytes, leaving an Img that pointed at a bucket which had never received them — every read (download, stream, thumbnail, converted-pdf) failed with "The specified bucket does not exist" / NoSuchKey and surfaced as a 500. Hit on the member Docs tab: an fw9.pdf uploaded to HR Resources and re-uploaded there kept its bytes only in imaging-hr-resources, so opening it in the e-sign editor gave "Failed to fetch PDF: 500" while /hr/resources opened the same file fine. Copy the dat's objects (original, converted rendition, thumbnails) into the target bucket at registration. Copying rather than reading from wherever they happen to live keeps associations independent: deleting the source document must not blank out the deduped one. A dat whose bytes exist nowhere now fails registration instead of creating a document that 500s on every read. Also declare commons-io directly: com.vonage:client drags in 2.5, which shadowed the 2.15.1 Spring Boot manages, and Tika 2.9.2 needs 2.7+ — on 2.5 the MimeTypeDetectionUtils static initializer dies with NoClassDefFoundError.