ENH: return more information on ConnectionError

[bsipocz]

I see more and more ConnectionError type tracebacks (I think it's just a side effect of we started testing more of the materials). One thing that comes to mind is that the traceback is never useful, and I wonder if/how we could make it more informative to users.

E.g. consider this tap query: https://github.com/Caltech-IPAC/irsa-tutorials/actions/runs/10806201868/job/30005528549#step:5:418

As a maintainer, I see that this is a temporary server side issue, but as a user I would value an easy way to see the actual query that was being sent up to the server (and even better, a copy pasteable URL that I could try in the browser; though I suspect that would be not exactly practical as we send our queries via requests rather than building up the query in a URL manually)

I remember various flavours of this same problem came up over the years, but couldn't dig up a currently open issue for it. Feel free to xref/or even close, if you find it otherwise.

[msdemlei]

On Wed, Sep 11, 2024 at 10:16:08AM -0700, Brigitta Sipőcz wrote: that was being sent up to the server (and even better, a copy pasteable URL that I could try in the browser; though I suspect that would be not exactly practical as we send our queries via `requests` rather than building up the query in a URL manually)

I suppose we first need to work out what exactly we would like to give in this situation. I suppose it would be something like The server at <url> has unexpectedly interrupted the connection. This usually means that the operators (<contact address>) are experiencing operational difficulties, which are usually temporary in nature. The recommended way to proceed would be to re-try after an hour and a day to give them time to recover. If that does not change the situation, feel free to inquire at the contact address. But then this already is so verbose that I doubt people will actually read it... sigh. Once we agree on what diagnostics we would like to have, the next question is whether we can produce it with some confidence, i.e., tell this situation from others (bad access URL, client network problem, faulty server-side software, pyVO bug, bad query, ...), because misleading detailed error messages are probably worse than incomprehensible ones. I currently have a student provoke errors on some set of services and classify the usefulness of pyVO's messages. If this goes anywhere, I think we will have a bit more material to discuss what behaviour we would like to have (perhaps in Malta?)

[ManonMarchand]

Does it only happen for 503 error codes? Could we confuse a server down with something else?

PS: I'll be in Malta 🙂

[msdemlei]

On Thu, Sep 12, 2024 at 12:59:30AM -0700, Manon Marchand wrote: Does it only happen for 503 error codes? Could we confuse a server down with something else?

Well... 502 sounds like a particularly good candidate for an elaborate explanation to me, as there's not much that could spuriously produce such a thing other than a backend server that's down. 503 I'm less confident about, partly because I've never raised one of these myself.

[ManonMarchand]

Then I don't feel like your message is too long, I like it.