- Shipped
- September 23, 2026 at 1:43 AM UTC
- Author
- Kamo
- Commit
- 90e477e
DocsService's imaging endpoints (download/stream/list/delete) know an Img's id but have no reason to hold the MediaObj it was attached to — until they need to honour the chat-attachment revoke flag on it (MediaObjImg.isAccessRevoked) without owning any chat/media schema themselves. MediaObjImgRepository only supported the other direction (by obj id, ordered, for rendering one message's attachments). findByImg_Id closes the gap; plural because the unique constraint is on (OBJ_ID, IMG_ID), not on IMG_ID alone. New test: MediaObjImgRepositoryQueryTest, pinning the derived query's signature the way **************** already does for its sibling repository (this library has no runnable @DataJpaTest/H2 harness, so a derived no-@Query method is asserted by reflection rather than exercised). Full suite: 3013 tests, 4 pre-existing failures + 1 pre-existing error, all confirmed present on a clean origin/main checkout before this change and unrelated to it (PhiServiceTypeMappingTest: ServiceType.KAMO_UNIVERSE has no PhiModule; **************** **************** unclaimed by a StorageDomain; ReportVisibilityTest: an off-by-one report count; SystemBugCountContractTest: SystemBugRepository.findVisible signature drift).