You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Garbled output when importing Gaia during maintenance #3469
Dear all,
It seems that the message is a landing page provided during downtimes. In any case, Gaia is currently under maintenance, the team is currently applying some upgrades. This is independent from the downtime that will be held between 5-10 Dec.
I will ping @cosmoJFH , so he can let us know when Gaia is available again.
In any case, maybe we could agree on a way to inform about our downtimes. Maybe we can create an issue warning our users about this...
In any case, maybe we could agree on a way to inform about our downtimes. Maybe we can create an issue warning our users about this...
I'm afraid users very likely won't notice the issues.
As I recall these message warnings were much shorter for the other modules during downtime, so maybe we just need to keep it short and concise rather than returning the whole page?
Yes, but if the services are down as well, no message will be provided. Maybe I can simply create an issue here informing all users?
Users don't tend to read issues, and even the few who open issues usually try to resolve the problem locally first, before they end up reporting it.
Maybe we should add some basic logic to parse this landing page and return some warnings/exceptions based on that rather than trying to return the whole page as in the OP above?
Yes, but if the services are down as well, no message will be provided. Maybe I can simply create an issue here informing all users?
Users don't tend to read issues, and even the few who open issues usually try to resolve the problem locally first, before they end up reporting it.
Maybe we should add some basic logic to parse this landing page and return some warnings/exceptions based on that rather than trying to return the whole page as in the OP above?
Mmm... this is something that only Gaia has, all the frontend URLs redirected to this page. For the rest of the Archives, an error 500 will be provided (I think). Then, maybe we can simply check during initialization if the connection to the TAP has really happened (e.g looking into the metadata) and, if not, provide a common message across the missions. This is something we can add to the code.
Yes, I had this problem as well. For what is worth, this helped a bit to tame the large number of warnings
# --------------------------------------------------------------------------------
# Gaia loader (astroquery) — distinguishes dependency vs asset/service problems
# --------------------------------------------------------------------------------
def load_Gaia(probe_service: bool = True):
"""
Return the astroquery.gaia.Gaia class.
Raises RuntimeError with a message distinguishing:
- astroquery not installed
- external Gaia assets/services unavailable
Parameters
----------
probe_service : bool, default True
If True, perform a tiny network-dependent check to detect
external service unavailability immediately. If False, only
import Gaia and let service failures occur later at first use.
Returns
-------
Gaia : type
The Gaia class from astroquery.gaia.
Raises
------
RuntimeError
With a distinguishing message for the two failure cases.
"""
# 1) Import-time: distinguish "not installed"
try:
from astroquery.gaia import Gaia
except ImportError as e:
raise RuntimeError(
"astroquery (or 'astroquery.gaia') is not installed in this environment."
) from e
# Optional: reduce astropy logger noise during later operations
try:
from astropy.logger import log
log.setLevel('ERROR')
from astropy.utils import iers
iers.conf.auto_download = False
iers.conf.auto_max_age = None
except Exception:
# If astropy settings change or aren't present, just continue.
pass
# 2) Service probe: distinguish "assets unavailable"
if probe_service:
try:
# Minimal, fast probe (hits TAP briefly):
Gaia.launch_job("SELECT TOP 1 source_id FROM gaiadr3.gaia_source", dump_to_file=False)
# Alternatively, if you want absolutely minimal probing:
# _ = Gaia.tap
except Exception as e:
raise RuntimeError(
"Gaia external assets/services appear unavailable or unreachable."
) from e
return Gaia
Activity
bsipocz commentedon Dec 1, 2025
This is unexpected.
cc @jespinosaar
jespinosaar commentedon Dec 2, 2025
Dear all,
It seems that the message is a landing page provided during downtimes. In any case, Gaia is currently under maintenance, the team is currently applying some upgrades. This is independent from the downtime that will be held between 5-10 Dec.
I will ping @cosmoJFH , so he can let us know when Gaia is available again.
In any case, maybe we could agree on a way to inform about our downtimes. Maybe we can create an issue warning our users about this...
cosmoJFH commentedon Dec 2, 2025
Hi,
it looks like that when the archive is under maintenance, the downtime page is returned.
Note that all the ESAC module would return a similar information, when their corresponding archive is down.
bsipocz commentedon Dec 2, 2025
I'm afraid users very likely won't notice the issues.
As I recall these message warnings were much shorter for the other modules during downtime, so maybe we just need to keep it short and concise rather than returning the whole page?
jespinosaar commentedon Dec 3, 2025
Yes, but if the services are down as well, no message will be provided. Maybe I can simply create an issue here informing all users?
bsipocz commentedon Dec 3, 2025
Users don't tend to read issues, and even the few who open issues usually try to resolve the problem locally first, before they end up reporting it.
Maybe we should add some basic logic to parse this landing page and return some warnings/exceptions based on that rather than trying to return the whole page as in the OP above?
jespinosaar commentedon Dec 4, 2025
Just FYI, Gaia should be up and running again
jespinosaar commentedon Dec 4, 2025
Mmm... this is something that only Gaia has, all the frontend URLs redirected to this page. For the rest of the Archives, an error 500 will be provided (I think). Then, maybe we can simply check during initialization if the connection to the TAP has really happened (e.g looking into the metadata) and, if not, provide a common message across the missions. This is something we can add to the code.
bsipocz commentedon Dec 4, 2025
Oh, I see. The 500 may get handled better as we have a few
raise_for_statusin the codekslong commentedon Dec 11, 2025
Yes, I had this problem as well. For what is worth, this helped a bit to tame the large number of warnings
for my code