BUG: return a less cryptic error for unavailable TAP url

[bsipocz]

The IRSA TAP url currently returns a 404, yet we get a rather cryptic error message and traceback with pyvo:

>>> from pyvo.dal import TAPService
>>> tap = TAPService('https://irsa.ipac.caltech.edu/TAP')
>>> query = '''SELECT TOP 10 ra,dec,id FROM cosmos2015'''
>>> result = tap.run_sync(query)

---------------------------------------------------------------------------
DALQueryError                             Traceback (most recent call last)
Cell In[4], line 1
----> 1 result = tap.run_sync(query)

File ~/munka/devel/pyvo/pyvo/dal/tap.py:278, in TAPService.run_sync(self, query, language, maxrec, uploads, **keywords)
    249 def run_sync(
    250         self, query, *, language="ADQL", maxrec=None, uploads=None,
    251         **keywords):
    252     """
    253     runs sync query and returns its result
    254 
   (...)
    274     TAPResults
    275     """
    276     return self.create_query(
    277         query, language=language, maxrec=maxrec, uploads=uploads,
--> 278         **keywords).execute()

File ~/munka/devel/pyvo/pyvo/dal/tap.py:1117, in TAPQuery.execute(self)
   1103 def execute(self):
   1104     """
   1105     submit the query and return the results as a TAPResults instance
   1106 
   (...)
   1115        for errors parsing the VOTable response
   1116     """
-> 1117     return TAPResults(self.execute_votable(), url=self.queryurl, session=self._session)

File ~/munka/devel/pyvo/pyvo/dal/adhoc.py:111, in AdhocServiceResultsMixin.__init__(self, votable, url, session)
    110 def __init__(self, votable, *, url=None, session=None):
--> 111     super().__init__(votable, url=url, session=session)
    112     self._adhocservices = list(
    113         resource for resource in votable.resources
    114         if resource.type == "meta" and resource.utype == "adhoc:service"
    115     )

File ~/munka/devel/pyvo/pyvo/dal/query.py:336, in DALResults.__init__(self, votable, url, session)
    334 self._status = self._findstatus(votable)
    335 if self._status[0].lower() not in ("ok", "overflow"):
--> 336     raise DALQueryError(self._status[1], self._status[0], url)
    338 if self._status[0].lower() == "overflow":
    339     warn("Partial result set. Potential causes MAXREC, async storage space, etc.",
    340          category=DALOverflowWarning)

DALQueryError: UsageFault: BAD_REQUEST: ODPI call failed.    function name:: dpiConn_create    ACTION: begin session   Message: ORA-03135: connection lost contact
Process ID: 0
Session ID: 0 Serial number: 0

[bsipocz]

OK, so this is a temporary/unexpected outage, and I'm not sure if we can improve anything on the pyvo side, as the response returned without an error, and the response votable had all the above UsageFault error we see above.

<Response [200]>
ipdb> self.queryurl
'https://irsa.ipac.caltech.edu/TAP/sync'
ipdb> rr.raw
<urllib3.response.HTTPResponse object at 0x102fd1cc0>
ipdb> rr.raw.read()
b'<?xml version="1.0" encoding="utf-8"?>\n<VOTABLE version="1.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ivoa.net/xml/VOTable/v1.3" xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.3 http://www.ivoa.net/xml/VOTable/v1.3">\n  <DESCRIPTION>Caltech/IPAC-IRSA IVOA Table Access Protocol (sync) Service</DESCRIPTION>\n  <RESOURCE type="results">\n    <INFO name="QUERY_STATUS" value="ERROR">UsageFault: BAD_REQUEST: ODPI call failed.    function name:: dpiConn_create    ACTION: begin session   Message: ORA-03135: connection lost contact\nProcess ID: 0\nSession ID: 0 Serial number: 0\n</INFO>\n  </RESOURCE>\n</VOTABLE>\n'

[msdemlei]

On Thu, Aug 15, 2024 at 03:20:24PM -0700, Brigitta Sipőcz wrote: OK, so this is a temporary/unexpected outage, and I'm not sure if we can improve anything on the pyvo side, as the response returned without an error, and the response votable had all the above UsageFault error we see above.

Hm -- I think part of the crypticity of the response probably is that it is not immediately obvious that the message comes from the guts of the remote service and thus is something that a user may not be able to influence. The trouble is that we cannot (or so I think) distinguish it from the case in which the user *can* change something (typically, bad ADQL). Perhaps we should have a longer look at the TAP standard to figure out whether we can better tell apart user-recoverable errors from non-user-recoverable errors and perhaps guide implementors. For the time being, perhaps it is already helpful if we just say something like "The remote server rejected your query. Its message was: ..."?