IDC viewer starts up and fails with a file not found

[wlongabaugh]

We are seeing cases where the IDC viewer is launched from the portal, the Viewer starts up and immediately reports it cannot access the file. An example: https://(test-viewer-redacted)/1.3.6.1.4.1.14519.5.2.1.163047965868107465659169009295180558950.

When looking at the proxy report, we see a request:

https://(test-proxy-redacted)/dicomWeb/studies/1.3.6.1.4.1.14519.5.2.1.163047965868107465659169009295180558950/series/undefined/metadata

Note the "undefined" series ID, which returns a 404. This glitch clears when the viewer is reloaded. It is also the case that this happens randomly, implying a race condition on startup where a request is issued before the series is identified, and subsequent requests do not have this problem.

[Punzo]

Hi @wlongabaugh I tired to reproduce in all tier (production, testing and dev), but I could not. Probably some running conditions. I will keep you posted if I manage to reproduce it.

[wlongabaugh]

Yes, it appears to be an intermittent race condition, so probably depends on when things show up on startup. One possibility would be to perhaps check if a request is being issued containing "/series/undefined/" and raise an error. Thanks.

[fedorov]

One possibility would be to perhaps check if a request is being issued containing "/series/undefined/" and raise an error.

This makes a lot of sense. More generally, could have a regex to discard strings that are not conforming with the UID (DICOM UI VR) character repertoire.

[Punzo]

that is a good idea, but it would be better if I manage to find the racing conditions and make the viewer wait for the series metadata. I will try again to reproduce it. In case, as final approach I will raise an error in case of "/series/undefined/"

[Punzo]

@wlongabaugh I tried again to reproduce the issue by throttling both/either network and CPU, but I had no success.

In the code I see that there is a wait/async call, therefore it is supposed to wait for the study metadata before firing any frame request. I am wondering if it is the google server failing to provide the full metadata and some gets corrupted.

Anyway, in #2908 I have added a check on StudyInstanceUID, SeriesInstanceUID and SOPInstanceUID and an error will be raised if they are not conforming with the UID (DICOM UI VR) character repertoire as suggested by @fedorov. The error is printed only to console, because the App services (like UI notifications) are not yet initialized at that point. On the other hand, it should continue to load the frames without blocking the App with the message 'file not found'.

[wlongabaugh]

It seems unlikely that the problem is on the Google side, since this problem is random, and typically (always?) works on a reload. Checks and logging statements to console around this issue are good to have. Thx.