Image loading error handling #474
Conversation
The json response from imageMarshal() may contain 'Exception' message but no pixel_size
|
I have removed renamed a file in ManagedRepo and then opened the image in iviewer. I get
|
|
With an image without pyramids I get
Interestingly, on Preview, there is no warning either (I realize this is for another PR) but it would be useful too, cf https://www.openmicroscopy.org/qa2/qa/feedback/41603/ |
src/model/image_info.js
Outdated
| if (response.ConcurrencyException) { | ||
| Ui.showModalMessage(`<p>Image is not currently viewable</p> | ||
| <pre>ConcurrencyException</pre> | ||
| <small>A pyramid of zoom levels is not available. Generation may be in progress if this is enabled on your server.</small>`, "OK"); |
There was a problem hiding this comment.
| <small>A pyramid of zoom levels is not available. Generation may be in progress if this is enabled on your server.</small>`, "OK"); | |
| <small>A pyramid of zoom levels is not available. Please contact your administrator, see https://omero.readthedocs.io/en/stable/sysadmins/limitations.html#large-images.</small>`, "OK"); |
I realize this ^^^ is not ideal suggestion, but I am against making of false hopes - as we do not recommend pyramid generation to be enabled, we should not assume (as the present comment does) that "waiting it out" is a good/default option.
There was a problem hiding this comment.
Bit of a side track... but those docs don't describe how to enable/disable pyramid generation. Do we have install docs that recommend and describe how to disable pyramid generation? This is likely to have an effect on how likely it is for a particular server to have pyramids disabled, since the default is still to be enabled, right?
Also those docs should mention https://www.glencoesoftware.com/products/ngff-converter/ .
Unfortunately it's not possible for a client to know if pyramids are disabled, since this gives a SecurityViolation:
conn.getConfigService().getConfigValue("omero.server.nodedescriptor")
How about.
"A pyramid of zoom levels is not available. Please contact your administrator if this does not resolve itself. See Limitations: Large Images"
There was a problem hiding this comment.
The property is actually "omero.server.nodedescriptors" and has been made user-visible since OMERO 5.6.6. Older versions of the server will definitely throw a SecurityViolation.
Note this is not necessarily the only way to disable the PixelData service e.g. you might have modified your templates manually but I think this is by far the option that is the most usable from an API perspective and the documentation should mostly likely document this workflow if any.
There was a problem hiding this comment.
@sbesson Thanks for catching my typo!
When connected to nightshade I get:
>>> conn.getConfigService().getConfigValue("omero.server.nodedescriptors")
''
Which would indicate that pyramid generation is enabled there?
For outreach server I get
'master:Blitz-0,Indexer-0,Processor-0,Storm,Tables-0'
There was a problem hiding this comment.
An empty value (default) means all services are enabled via configuration - see https://omero.readthedocs.io/en/stable/sysadmins/config.html#omero-server-nodedescriptors
There was a problem hiding this comment.
Great. Since clients can access this, I'll load it from iviewer so we can show a more useful error message for ConcurrencyException. It probably makes sense that we do something similar in webclient too, but most useful would be the Importer, since you need to know at import time if you're importing a Big Image without pyramids.
|
How to elicit |
|
The The code comment says
|
|
With that last commit, we try to load the
Otherwise it's probable that we can generate pyramids (unless this is disabled on an older server that doesn't allow us to query it), so we show this:
|
|
With a "large" image without pyramids, I am having the two messages if pyramid gen is a) disabled (first screenshot) or b) enabled (second screenshot). Lgtm |
|
I understand that #474 (comment) is very hard to elicit and was never encountered, actually the error is being caught for completeness sake. Lgtm in total. |
Fixes #473
This improves the error handling for loading image data when you first open iviewer.
Previously we only handled
404 Image not found, but if any JSON data was returned, even with exceptions, then these were ignored and the viewer would silently fail.I have handled the possible Errors etc that are reported by the python error handling at various stages, such as ConcurrencyException and other catch-all exceptions:
To test, you need to generate or find broken images (or missing pyramids etc).
Most of the testing I've done has been by artificially adding errors at particular points in the python code.