Fix Version/s: None
Team:Science User Interface
Gregory Dubois-Felsmann 4:49 PM
So I think what is happening is that a) the initialization code for the TAP query screen is running even before it’s actually invoked (this is an issue of the way the JS application is structured that is way out of my current level of knowledge) and b) it’s seeing the URL of the JupyterLab session, perhaps, instead of the Portal — or it’s seeing the non-standard (instance)/firefly URL that Adam controls. If it’s the latter, though, I don’t know why it would be running the TAP initialization code, because that’s not in the application that Adam runs.
All of which is to say, Adam is correct: if the base URL from which the application is trying to deduce the TAP URL were in the error message, there would be less speculation involved here.
But still: something changed from Wednesday, and it certainly wasn’t something we did on our side.
Christine Banek 4:51 PM
well one thing that I think may have changed (or even probably changed) is now jupyter is probably pointing at a different of the many firefly urls
I believe yesterday jupyter -int's firefly pointed at an internal firefly jupyter which was at -int.ncsa.illinois.edu/firefly, now it's pointing at /portal/app
Gregory Dubois-Felsmann 4:52 PM
OK, so I do see the message when Jupyter loads, and I agree, it must be part of the initialization of the application.
Christine Banek 4:53 PM
so we might have implicitly kind of changed what firefly version jupyter is talking to
Gregory Dubois-Felsmann 4:53 PM
Yes, I think you did.
Christine Banek 4:53 PM
but it does seem to work, we ran the firefly notebook and it worked
Gregory Dubois-Felsmann 4:57 PM
I think the only issue is that the LSST Portal application (which is what you are now running after what you changed - you used to be running “vanilla” Firefly) uses window.location.href in the TAP initialization code to introspect on where it’s running. Apparently when this runs inside JupyterLab it sees https://lsst-lsp-int.ncsa.illinois.edu/nb/user/gpdf/lab or something like that. It’s expecting to see (scheme)://(hostname)/(optional stuff)/portal/(anything) and then it works back from that to decide that the TAP service is at (scheme)://(hostname)/(optional stuff)/api/tap .
So there’s no “portal” in the window-level property window.location.href when it runs under JupyterLab and this logic fails. (edited)
It doesn’t use just (hostname) because we wanted to be robust to possible LSP deployments with a pathname component in the instance, like some future https://www.lsst.org/lsp/api/tap / https://www.lsst.org/lsp/portal situation, or something analogous in the cloud.
If we had just naively used the hostname alone, this would have accidentally been OK.
Christine Banek 5:01 PM
well it's not a big thing, it's just annoying because it comes up everytime someone logs in. but it seems like just some debt we've uncovered in getting to just one copy of the portal running
because it sounds like this configuration should work, and is what we want, right?
Gregory Dubois-Felsmann 5:02 PM
Yes, that’s right. What we really wanted is to get the URL of the Firefly server, though, not the URL of the JL session. I wonder if that’s available in a way that isn’t itself fragile in some other way.
We have to autodetect the URL for TAP or there will be a credential mismatch - we can’t just hard-code -stable or something like that.
We’ll have to think about this.