Simbad query_objects() raises DALQueryError for first time running it on a clean machine

[henrysky]

On Github action or Google Colab, simbad query_objects() raises DALQueryError running for the first time ever on a clean machine for astroquery 0.4.9.

The way to reproduce on Google Colab (make sure it is a new runtime that you have to install astroquery, not just restart with a new session). Running

from astroquery.simbad import Simbad
simbad = Simbad()
simbad.query_objects(['LMC', 'M31'])

raises

DALQueryError                             Traceback (most recent call last)
[<ipython-input-2-03fcb3ecdc5e>](https://localhost:8080/#) in <cell line: 0>()
      1 from astroquery.simbad import Simbad
      2 simbad = Simbad()
----> 3 simbad.query_objects(['LMC', 'M31'])

5 frames
[/usr/local/lib/python3.11/dist-packages/pyvo/dal/tap.py](https://localhost:8080/#) in raise_if_error(self)
    990                 msg = self._job.errorsummary.message.content
    991             msg = msg or "<No useful error from server>"
--> 992             raise DALQueryError("Query Error: " + msg, self.url)
    993 
    994     def fetch_result(self):

DALQueryError: Query Error: Error while reading the table "script_infos": Failed to read the table 'script_infos'! Cause: no file found.

and then simply running

simbad.query_objects(['LMC', 'M31'])

again gives correct result without errors. Even if you restarting a new session, query_objects() works fine without issue.

[bsipocz]

I can reproduce this, too.

This looks to be a weird one, cc @ManonMarchand

[keflavich]

Weird. I can reproduce this. clear_cache does not reproduce it, it only happens in a fresh enviroment.

[ManonMarchand]

Investigations so far:

• I cannot reproduce in a fresh conda environment nor in a fresh uv environment, it's only google colab
• I can also reproduce without query_objects and with a simple query_tap

from astroquery.simbad import Simbad
from astropy.table import Table
table = Table({"a": [1, 2, 3]})
simbad = Simbad()
simbad.query_tap("select * from TAP_UPLOAD.local_table", local_table=table)

but it has to contain an upload to reproduce

EDIT: Ahah got it to bug with only PyVO:

from pyvo.dal.tap import TAPService
from astropy.table import Table
tap = TAPService("https://simbad.cds.unistra.fr/simbad/sim-tap/")
table = Table({"a": [1, 2, 3]})
tap.run_async("select * from TAP_UPLOAD.local_table", uploads={"local_table": table})

The synchrone mode does not bug.

A dirty fix in astroquery would be to switch queries with uploaded tables to synchrone mode (but the hardlimit on the timeout is lower, so it might be an issue for some users). There is definitely something wrong happening upstream, either in pyvo or in google colab.

Warnings and errors in Colab's console:

Details

Feature Policy: Skipping unsupported feature name “accelerometer”. external_binary.js:4674:442
Feature Policy: Skipping unsupported feature name “autoplay”. external_binary.js:4674:442
Feature Policy: Skipping unsupported feature name “gyroscope”. external_binary.js:4674:442
Feature Policy: Skipping unsupported feature name “magnetometer”. external_binary.js:4674:442
Feature Policy: Skipping unsupported feature name “xr-spatial-tracking”. external_binary.js:4674:442
Feature Policy: Skipping unsupported feature name “clipboard-write”. external_binary.js:4674:442
Feature Policy: Skipping unsupported feature name “accelerometer”. external_binary.js:221:692
Feature Policy: Skipping unsupported feature name “autoplay”. external_binary.js:221:692
Feature Policy: Skipping unsupported feature name “gyroscope”. external_binary.js:221:692
Feature Policy: Skipping unsupported feature name “magnetometer”. external_binary.js:221:692
Feature Policy: Skipping unsupported feature name “xr-spatial-tracking”. external_binary.js:221:692
Feature Policy: Skipping unsupported feature name “clipboard-write”. external_binary.js:221:692
Feature Policy: Skipping unsupported feature name “accelerometer”. external_binary.js:4672:80
Feature Policy: Skipping unsupported feature name “autoplay”. external_binary.js:4672:80
Feature Policy: Skipping unsupported feature name “gyroscope”. external_binary.js:4672:80
Feature Policy: Skipping unsupported feature name “magnetometer”. external_binary.js:4672:80
Feature Policy: Skipping unsupported feature name “xr-spatial-tracking”. external_binary.js:4672:80
Feature Policy: Skipping unsupported feature name “clipboard-write”. external_binary.js:4672:80
No output window available external_binary.js:4685:408
Partitioned cookie or storage access was provided to “https://4uokefuz70i-496ff2e9c6d22116-0-colab.googleusercontent.com/outputframe.html?vrz=colab_20250205-060136_RC00_723469086” because it is loaded in the third-party context and dynamic state partitioning is enabled.

Using //@ to indicate sourceURL pragmas is deprecated. Use //# instead
outputframe.html:240:15
Source map error: Error: request failed with status 404
Stack in the worker:networkRequest@resource://devtools/client/shared/source-map-loader/utils/network-request.js:43:9

Resource URL: https://4uokefuz70i-496ff2e9c6d22116-0-colab.googleusercontent.com/outputframe.html?vrz=colab_20250205-060136_RC00_723469086
Source Map URL: outputframe.css.map

No warnings nor error the second time around.

Decomposing a bit what run_async does:

from pyvo.dal.tap import TAPService, AsyncTAPJob
from astropy.table import Table
simbad = TAPService("https://simbad.cds.unistra.fr/simbad/sim-tap/")
table = Table({"a": [1, 2, 3]})
job = AsyncTAPJob.create(
            simbad.baseurl, "select * from TAP_UPLOAD.local_table", uploads={"local_table": table},
            session=simbad._session)
print("job id: ", job.job_id)

no errors in the console, and the job is created normally on the server side. When we do:

job.run()

The job has an upload error on the server side.

[bsipocz]

I managed to reproduce it locally, rather than on colab, but after the first run it keep working no matter how much I clean up the env (uninstalling asyroquery and pyvo is apparently not enough)

[keflavich]

Ditto @bsipocz. Does pyvo cache something somewhere?

[ManonMarchand]

I still cannot reproduce locally. How did you create the environment? Just tried an old classic venv on top of conda and uv

[keflavich]

I don't know! I just tried it in my existing environment, and the first attempt reproduced the above failure, but all subsequent attempts failed to fail (succeeded). I don't know how to get back to the failing state, which unfortunately makes this rather difficult to debug.

[henrysky]

I have just tried on two computing servers (denoted as server A and B, with different IP addresses) with a shared user directory between the two. Running the query_objects() on server A for the first time raised DALQueryError but not subsequent runs. And then login to server B running the query_objects() the first time also raised DALQueryError! So must not be any cache file under my user directory, otherwise should not be any DALQueryError on server B.

On my laptop which I have encountered DALQueryError before (but not anymore), I simply change the wifi to use my phone hotspot and guess what? I have have encountered DALQueryErroragain with the same python enviroment!

Then I dig out one of my old laptop (haven't used it for a few months) and try, query_objects() WITHOUT DALQueryError at the first time using the same wifi as my current laptop!

I agree this might be a server side problem where this problem somehow happen only once for each IP address?

[ManonMarchand]

Thank you, that's a good clue!

[ManonMarchand]

I reproduced it in TOPCAT with a new IP address.
However, the investigation will have to wait a bit because it's the start of the winter holiday in France. I'll be back on it in two weeks, sorry

[bsipocz]

A dirty fix in astroquery would be to switch queries with uploaded tables to synchrone mode (but the hardlimit on the timeout is lower, so it might be an issue for some users). There is definitely something wrong happening upstream, either in pyvo or in google colab.

Unrelated to this particular issue, but you may be interested in my approach of providing both sync and async TAP. OK, IRSA was different than simbad in a sense that we default to sync and then started to run into timeouts and other issues when people were running bigger queries, so I added async: #3201