When I run galaxy locally, the NGL viewer displays PDB files and the controls kinda work (radius needs to be set to at least 0.3 for the colouring schemes, e.g, ‘colour by B-factor’ to have any effect).
On our production instance (galaxy 22.01 gunicorn/nginx), the NGL viewer displays PDB files but the controls do not work at all (click on any option=> nothing happens). The javascript console shows:
Errors:
ngl.js:3 makeRepresentation: representation type undefined unknown
ngl.js:3 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading ‘type’)
at new Sa (ngl.js:3:227062)
at a._getRepresentationComponent (ngl.js:3:826061)
at Ba.addRepresentation (ngl.js:3:824925)
at Ba.addRepresentation (ngl.js:3:854042)
at ngl.js:5:1055
I have checked that the PDB file shows in the History as format = pdb.
I tried to rebuild the plugin with:
cd ~/galaxy/config/plugins/visualizations/ngl
yarn run build
Still the NGL controls don’t work
Grateful for any hints!
This is a good question for our admins. I’ve cross-posted over to their chat, and replies may be here or there. Please feel free to join the chat too. You're invited to talk on Matrix
It looks like admins were unable to help, so posting more info here in the hope another user may have suggestions.
My NGINX config is the default:
# serve visualization and plugin static content
location ~ ^/plugins/(?<plug_type>.+?)/(?<vis_name>.+?)/static/(?<static_file>.*?)$ {
alias $galaxy_root/config/plugins/$plug_type/$vis_name/static/$static_file;
expires 24h;
}
Some oddities:
A) the ngl static files are not under /config/plugins/visualizations/ngl/static but in a ‘dist’ subdirectory.
=> I copied the dist files into ngl/static, restarted NGINX. Made no difference, the controls still don’t work
B) the ngl tool is trying to access https://mygalaxy.domain.server/ngl.js.map and fails with a 404 Not Found.
=> I don’t understand how galaxy is dealing with this under the hood, but if I run galaxy locally on my mac, it throws the same 404 warning but the controls do work
Maybe this will help? Versions of releases can be navigated (and sometimes matter), and much of the content is populated directly from the code base. If a particular file is not “sniffed” how you expect it to be, that is usually important, and for your specific UI issue, seems relevant. Data Types — Galaxy Project 23.2.dev0 documentation
Then, try different PDBs from different sources and see if you can find the difference. I guess you could also try re-installing the datatype to test if that is enough or the process logs provide any clues.
If the Galaxy base release is different, that could be one reason why. Older functions/tools have a high priority to stay supported in newer releases but the reverse has a lower priority of course, and in some cases, just not a possible.
Upgrading Galaxy itself might be needed (ducks)… but that is just a default recommendation. Digging in more to find if there were any PRs made to support the datatype (specifically, or in general for some class of types) and patching those into your server are another possible. All are guesses of course.
I’d suggest trying to figure out exactly why the datatype isn’t auto-detected first by eliminating a file issue (it happens), and updating the spec for the type (or, reverting back to a version better pairs temporally with your Galaxy version), then make decisions from there. This can spin out to all kinds of custom changes to the datatype, tool wrappers, etc if the people using your server need something special for files from a particular source. Then you could contribute any changes to the primary code sources. This is not uncommon but should target the most current release (or better, in dev releases) unless compelling enough to warrant retroactive patches (unlikely unless a serious bug eg security concern).
That’s what I have! The devs/admins tend to not get into corner case troubleshooting older releases for the usual reasons… but feel free to post back your updates and solution to this thread. Many groups host older releases and those admins will search at this forum (or just internet search and land here).
Thank you @jennaj . My first reply was wrong, I got confused with ‘autodetect on upload’ vs ‘autodetect after manual setting of datatype’… it’s confusing that the Data Libraries upload form shows type=‘autodetect’ even when I set the datatype to ‘pdb’ manually!
Auto-detect on upload fails for PDB in both versions, regardless of where the PDB file comes from (downloaded from PDB or generated by Phenix). I get a warning in both version 22.01 and 22.05 that “The file ‘Type’ was set to ‘pdb’ but the file does not appear to be of that type” with Phenix pdb files.
It looks again like a production vs local settings where galaxy is not playing well with gunicorn/nginx. Unfortunately, the bug is happening inside the NGL plugin javascript code that fails to communicate with the galaxy python.
Thanks for posting this back. You could check our code base for any changes in more recent releases to see if something changed that would be related.
And, I can’t remember if you tried this yet (just as an extra check) – are the files given the correct auto-detected datatype at a public server? Might have more clues.
Once you narrow this down, you could try the admin chat again. If there is a specific problem we can address in the Galaxy code base that makes the applications play together better, maybe a change could be made.
The data type is a red herring and unrelated:
again: I am getting the same data type errors and warnings in local version 22.01 and gunicorn/nginx version 22.05.
=> Therefore data type is totally and utterly irrelevant.
The problem can be solved with a UNIX sysadmin expert who understands how galaxy works, how the ngl plugin works and how gunicorn/nginx works.
I deleted the post that had wrong information about data type.
The real problem: galaxy is blocking the passing of the “representation type” parameter from the NGS visualizer display to the NGS visualizer control panel when galaxy is running behind gunicorn/nginx.
This bug does not exist when galaxy is run locally, i.e. started via direct call to run.sh from command line.
Thanks @jennaj , I am still unsure about what’s going on. Today our production galaxy server is even slower than usual, and I’m getting the ngl.js errors (“makeRepresentation: representation type undefined unknown” and “Uncaught (in promise) TypeError: Cannot read properties of undefined (reading ‘type’)” ) upon display, before I open the controls! The display still shows the structure and I can interact with the display. But the controls don’t work.
I’m wondering if the issue is a timeout?
I attempted to visualize the same pdb file on usegalaxy.org:
display and controls work
the JS console shows
error: [Intervention] Unable to preventDefault inside passive event listener due to target being treated as passive. See Chrome Platform Status
h @ events.js:54
warning: DevTools failed to load source map: Could not load content for https://usegalaxy.org/ngl.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE
Since you can reproduce this at a public server, please file a bug report for it. The form includes all the details to include and our team will do the triage. All development is public.
Hello @jennaj , I’m a bit confused: how did my post led you to understand that I can reproduce the bug on the public server? I wrote: display and controls work as the first point!
I really meant what I wrote: the NGL viewer on the public server works fine. It throws errors in the javascript console, but that does not appear to affect functionality.
Just to be absolutely clear: on usegalaxy.org, I cannot reproduce the bug that I see on our gunicorn/nginx production galaxy.
Is there a configuration option that limits how visualization tools are loaded when galaxy is served behind nginx and gunicorn?
I noticed that on our production server, the NGL viewer window gets stuck during loading: the top left-hand corner of the PDB display shows a loading wheel “Please wait…”
