Possible DCM4CHEE-ARC-LIGHT BUG Using the Recreate DB Record Removes Storage Location Information

[Michael-Andersen]

I have been playing around with the Recreate DB Record functionality. My PACS is configured with two file systems a main archive disk: "archive" , and a smaller cache disk "cache". I have configured it so that every study lives on the archive disk but recently retrieved studies get copied to the cache and once a storage threshold is exceeded the studies are cleared from the cache.

Using Recreate DB Record, I have found that sometimes studies will lose their location reference to the archive disk and only retain the cache location data. As a result once the storage threshold is exceeded on the cache, the studies can't be deleted because for some instances "they don't exist on archive". In reality, I believe they do still exist on archive but the database record doesn't indicate this.

I have tried using different Recreate DB Record options such as OVERWRITE, MERGE, and SUPPLEMENT and I think all three can still produce this bug. But perhaps I'm misunderstanding how recreate DB Record is supposed to work. Is there anyone that could walk me through the options I should use to prevent this scenario from happening? Or can we confirm this is a bug and work on a fix for an upcoming release?

Any help on this issue would be greatly appreciated, Thanks!

[vrindanayak]

I don't understand why the cache / long term archive is mixed up with Recreate DB Record functionality.

Recreate DB Record function in UI (#3823) essentially invokes REST API Reimport Study (#2983) which in itself was an extension improvement to REST API Import Instances on Storage (#2105). (Note : There is no UI function for Import Instances on Storage)

• The purpose of these REST APIs and corresponding UI function for one of them was to enable easier importing of DICOM files already present on a storage location and creating directly DB records for them without having the need to store again explicitly (migration purposes).
• With re-import, it goes one step further and enable doing same with an added step of deleting records from DB if already present and then doing same as the first API (allows importing objects from filesystem without storing to archive if archive already contains studies which may be stale)

[Michael-Andersen]

Thanks for the clarification about what these endpoints are for. I experimented with them to resolve our study size tag issue. I believe the issue here is that after recreating the db record only the cache location metadata info is retained. It's possible this bug is also related to our practice of polling DCM4CHEE every few minutes to scrap metadata which might be causing a db connection leak. I will into the simplest way to reproduce this bug.

[Michael-Andersen]

I tried using "Import Instances" API to see if I could get a proper db record for the studies which are sitting on our archive disk but no longer have accurate location information in the db. I got a 409 conflict response. Is this because other instances on the archive disk are already imported?