Improve frontend error messages if the backend is down

[gaurav]

The previous error described below has been fixed, but while it was in effect, we didn't display clear error messages indicating that the backend was down. I'll use this issue to fix that, then close it.

---

Previous error

For quite a long time, we have been using a @context of https://www.phyloref.org/phyx.js/context/v1.0.0/phyx.json in our JSON-LD files, and this has been working on the Hipergator backend for all of this time.

Recently, some change on either Hipergator or GitHub has caused this URL to no longer work. Jobs running in the cluster need to use a local proxy server to talk to the internet. I can download this file just fine on Hipergator:

[flmnh@pubapps1 tmp]$ wget "https://www.phyloref.org/phyx.js/context/v1.0.0/phyx.json"
--2024-03-08 14:41:21--  https://www.phyloref.org/phyx.js/context/v1.0.0/phyx.json
Resolving [PROXY SERVER]
Connecting to [PROXY SERVER]... connected.
WARNING: certificate common name “*.github.io” doesn’t match requested host name “www.phyloref.org”.
Proxy request sent, awaiting response... 200 OK
Length: 3883 (3.8K) [application/json]
Saving to: “phyx.json.6”

100%[================================================>] 3,883       --.-K/s   in 0s      

2024-03-08 14:41:21 (38.8 MB/s) - “phyx.json.6” saved [3883/3883]

But trying to reason over a phyloreference results in a "Could not parse JSONLD" error:

[flmnh@pubapps1 webhook]$ srun -s --ntasks=1 --cpus-per-task=4 --mem=16G -t 2 java -Dhttp.proxyHost=[PROXY SERVER] -Dhttp.proxyPort=3128 -Dhttps.proxyHost=[PROXY SERVER] -Dhttps.proxyPort=3128 -Xmx16G -jar jphyloref-1.1.1.jar resolve test.jsonld -j 
srun: job 2897 queued and waiting for resources
srun: job 2897 has been allocated resources
[main] INFO org.phyloref.jphyloref.commands.ResolveCommand - Input: brochu.jsonld
[main] INFO org.phyloref.jphyloref.commands.ResolveCommand - Found local ontologies: [http://ontology.phyloref.org/tcan.owl, http://ontology.phyloref.org/phyloref.owl]
Unexcepted exception while reasoning over 'brochu.jsonld': org.eclipse.rdf4j.rio.RDFParseException: Could not parse JSONLD
srun: error: pubcompute2: task 0: Exited with exit code 1

However, if I change the path to https://raw.githubusercontent.com/phyloref/phyx.js/master/docs/context/v1.0.0/phyx.json, reasoning works fine. Note that this produces the same warning as the other request:

[flmnh@pubapps1 tmp]$ wget "https://raw.githubusercontent.com/phyloref/phyx.js/master/docs/context/v1.0.0/phyx.json"
--2024-03-08 14:44:50--  https://raw.githubusercontent.com/phyloref/phyx.js/master/docs/context/v1.0.0/phyx.json
Resolving [PROXY SERVER]
Connecting to [PROXY SERVER]... connected.
WARNING: certificate common name “*.github.io” doesn’t match requested host name “raw.githubusercontent.com”.
Proxy request sent, awaiting response... 200 OK
Length: 3883 (3.8K) [text/plain]
Saving to: “phyx.json.7”

100%[================================================>] 3,883       --.-K/s   in 0s      

2024-03-08 14:44:50 (39.0 MB/s) - “phyx.json.7” saved [3883/3883]

I'm still trying to work out why both of those URLs work in wget but one of them works in JPhyloRef (or rather, in the rdf4j library we use). The only difference I can spot is that the former returns a MIME type of application/json, while the latter returns text/plain.

[gaurav]

This is now working again -- there wasn't anything wrong with our code, but we needed to move our backend to a different node. However, I notice that we weren't displaying clear error messages when the backend was down -- so I'll use this ticket to track improving the error messages if the backend is down.

[gaurav]

We currently display an alert() box -- we don't have a way to detect when there is a connection issue as compared to some other issue, so we report this as an "unknown error".

@hlapp Do you think this is good enough for v1.0, or should we try to detect connection issues and report that separately?

[hlapp]

For the end user arguably it doesn't make a difference why there's an issue with connecting to the reasoner – the effect is the same, and no matter what the reason, they can't fix it. That is, unless they don't have a working network connection. But then they'll presumably have other issues too, so they'll probably already know that.

So in short, I think at the point we're at this is tinkering around the edges and can be left for down the road.