Repository navigation
Test failures with remote_data=True #4896
Description
Someone should turn on remote_data and do a test before 1.2 release. I get the following failures on my machine (the last one cracks me up):
================================== FAILURES ===================================
___________________ test_database_specify[ngc 3642-db_dict0] ___________________
name = 'ngc 3642'
db_dict = {'all': '# ngc3642 #Q22523722
#=S=Simbad (via url): 1
%@ 503952
%I.0 NGC 3642
%C.0 LIN
%C.N0 15.15.01.00
%J 170....V=VizieR (local): 1
%J 170.56 +59.08 = 11:22.2 +59:05
%I.0 {NGC} 3642
#====Done (2013-Feb-12,16:37:42z)===='}
@remote_data
@pytest.mark.parametrize(("name", "db_dict"), [('ngc 3642', _cached_ngc3642),
('castor', _cached_castor)])
def test_database_specify(name, db_dict):
# First check that at least some sesame mirror is up
for url in sesame_url.get():
if urllib.request.urlopen(url).getcode() == 200:
break
else:
pytest.skip("All SESAME mirrors appear to be down, skipping "
"test_name_resolve.py:test_database_specify()...")
for db in db_dict.keys():
with sesame_database.set(db):
try:
icrs = SkyCoord.from_name(name)
except NameResolveError:
> ra, dec = db_dict[db]
E ValueError: too many values to unpack
.../astropy/coordinates/tests/test_name_resolve.py:160: ValueError___________________ test_database_specify[ngc 3642-db_dict0] ___________________
name = 'ngc 3642'
db_dict = {'all': '# ngc3642 #Q22523722\n#=S=Simbad (via url): 1\n%@ 503952\n%I.0 NGC 3642\n%C.0 LIN\n%C.N0 15.15.01.00\n%...eR (local): 1\n%J 170.56 +59.08 = 11:22.2 +59:05\n%I.0 {NGC} 3642\n\n\n\n#====Done (2013-Feb-12,16:37:42z)===='}
@remote_data
@pytest.mark.parametrize(("name", "db_dict"), [('ngc 3642', _cached_ngc3642),
('castor', _cached_castor)])
def test_database_specify(name, db_dict):
# First check that at least some sesame mirror is up
for url in sesame_url.get():
if urllib.request.urlopen(url).getcode() == 200:
break
else:
pytest.skip("All SESAME mirrors appear to be down, skipping "
"test_name_resolve.py:test_database_specify()...")
for db in db_dict.keys():
with sesame_database.set(db):
try:
icrs = SkyCoord.from_name(name)
except NameResolveError:
> ra, dec = db_dict[db]
E ValueError: too many values to unpack
.../astropy/coordinates/tests/test_name_resolve.py:160: ValueError
_____________________ test_constellations_with_nameresolve _____________________
@remote_data
def test_constellations_with_nameresolve():
assert SkyCoord.from_name('And I').get_constellation(short_name=True) == 'And'
#you'd think "And ..." should be in Andromeda. But you'd be wrong.
assert SkyCoord.from_name('And VI').get_constellation() == 'Pegasus'
#maybe it's because And VI isn't really a galaxy?
assert SkyCoord.from_name('And XXII').get_constellation() == 'Pisces'
assert SkyCoord.from_name('And XXX').get_constellation() == 'Cassiopeia'
#ok maybe not
#ok, but at least some of the others do make sense...
assert SkyCoord.from_name('Coma Cluster').get_constellation(short_name=True) == 'Com'
> assert SkyCoord.from_name('UMa II').get_constellation() == 'Ursa Major'
.../astropy/coordinates/tests/test_sky_coord.py:1162:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
.../astropy/coordinates/sky_coordinate.py:1174: in from_name
icrs_coord = get_icrs_coordinates(name)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
name = 'UMa II'
def get_icrs_coordinates(name):
"""
Retrieve an ICRS object by using an online name resolving service to
retrieve coordinates for the specified name. By default, this will
search all available databases until a match is found. If you would like
to specify the database, use the science state
``astropy.coordinates.name_resolve.sesame_database``. You can also
specify a list of servers to use for querying Sesame using the science
state ``astropy.coordinates.name_resolve.sesame_url``. This will try
each one in order until a valid response is returned. By default, this
list includes the main Sesame host and a mirror at vizier. The
configuration item `astropy.utils.data.Conf.remote_timeout` controls the
number of seconds to wait for a response from the server before giving
up.
Parameters
----------
name : str
The name of the object to get coordinates for, e.g. ``'M42'``.
Returns
-------
coord : `astropy.coordinates.ICRS` object
The object's coordinates in the ICRS frame.
"""
database = sesame_database.get()
# The web API just takes the first letter of the database name
db = database.upper()[0]
# Make sure we don't have duplicates in the url list
urls = []
domains = []
for url in sesame_url.get():
domain = urllib.parse.urlparse(url).netloc
# Check for duplicates
if domain not in domains:
domains.append(domain)
# Add the query to the end of the url, add to url list
fmt_url = os.path.join(url, "{db}?{name}")
fmt_url = fmt_url.format(name=urllib.parse.quote(name), db=db)
urls.append(fmt_url)
for url in urls:
try:
# Retrieve ascii name resolve data from CDS
resp = urllib.request.urlopen(url, timeout=data.conf.remote_timeout)
resp_data = resp.read()
break
except urllib.error.URLError as e:
# This catches a timeout error, see:
# http://stackoverflow.com/questions/2712524/handling-urllib2s-timeout-python
if isinstance(e.reason, socket.timeout):
# If it was a timeout, try with the next URL
continue
else:
raise NameResolveError(
"Unable to retrieve coordinates for name '{0}'; "
"connection timed out".format(name))
except socket.timeout:
# There are some cases where urllib2 does not catch socket.timeout
# especially while receiving response data on an already previously
# working request
raise NameResolveError(
"Unable to retrieve coordinates for name '{0}'; connection "
"timed out".format(name))
# All Sesame URL's timed out...
else:
raise NameResolveError("All Sesame queries timed out. Unable to "
"retrieve coordinates.")
ra, dec = _parse_response(resp_data)
if ra is None and dec is None:
if db == "A":
err = "Unable to find coordinates for name '{0}'".format(name)
else:
err = "Unable to find coordinates for name '{0}' in database {1}"\
.format(name, database)
> raise NameResolveError(err)
E NameResolveError: Unable to find coordinates for name 'UMa II'
.../astropy/coordinates/name_resolve.py:173: NameResolveError
___________________ TestFileFunctions.test_open_nonexistent ____________________
self = <astropy.io.fits.tests.test_core.TestFileFunctions object at 0x7f6b58687cd0>
def test_open_nonexistent(self):
"""Test that trying to open a non-existent file results in an
IOError (and not some other arbitrary exception).
"""
try:
fits.open(self.temp('foobar.fits'))
except IOError as e:
> assert 'No such file or directory' in str(e)
E assert 'No such file or directory' in "[Errno 2] Datei oder Verzeichnis nicht gefunden: '/tmp/fits-test-Y2tDbp/foobar.fits'"
E + where "[Errno 2] Datei oder Verzeichnis nicht gefunden: '/tmp/fits-test-Y2tDbp/foobar.fits'" = str(IOError(2, 'Datei oder Verzeichnis nicht gefunden'))
.../astropy/io/fits/tests/test_core.py:598: AssertionError
======= 4 failed, 9850 passed, 73 skipped, 42 xfailed in 262.66 seconds ========
1
Activity
bsipocz commentedon May 13, 2016
hmm, I saw the coordinates ones before (there is also an issue somewhere), and started to have a look, but didn't have time to get anywhere with the fix.
astrofrog commentedon May 13, 2016
What? Why is there an error message in German? Did someone mess with the locale? 🇩🇪
pllim commentedon May 13, 2016
ich weiß es nicht ¯_(ツ)_/¯
pllim commentedon May 13, 2016
By the way, my locale is:
eteq commentedon May 16, 2016
There's actually two problems in the first two name resolve errors: one is that the "real" error is hidden (see #4925), and the second is whatever the underlying error is (hard to diagnose without #4925). But I see the same.
The last two are baffling, though. I have no idea what's up with the 🇩🇪... But the other one is especially strange because it works fine for me - just tried right now.
I wonder if it's a network thing? I've seen hints of this before where sesame name resolve calls seem to go to different servers depending on where you are, and they aren't always synced. But that's strange given that @pllim and I should be on very similar networks, as we're in the same city... As a wild guess, @pllim, did you do this from a computer inside the STScI network? Can you try from outside the network if so (or inside the network if not)?
pllim commentedon May 16, 2016
@eteq , it was done on RHEL6 64-bit, Python 2, Anaconda, internal network.
Regarding the non-German error that you didn't get (I assume you're talking about "UMa II"), did you do your test on Python 3? If so, could it be a
unicode_literalsthing? I recently run into troubles with that import in my other projects.I cannot hook this RHEL6 on external network, but I can try that on a Windows laptop...
pllim commentedon May 16, 2016
Update: No luck on my Windows laptop. I get "Python has stopped working" at
io/fits/test_checksum.py... 🙈pllim commentedon May 16, 2016
Back to my Linux machine, using #4925:
This is what I get when running
astropy.test(remote_data=True)in a Python session (not IPython) that is started outside of the source directory (3 errored tests):astropy_test_err.txt
This is what I get when running
python setup.py test --remote-datafrom the source directory (4 errored tests but the last one I think is just me not having some optional dependency package installed):astropy_test_err_codedir.txt
MSeifert04 commentedon May 16, 2016
I can confirm this.
pllim commentedon May 16, 2016
I still don't know why my FITS test error message is not in English, because it is English when I try to open a non-existing file manually:
21 remaining items
astrofrog commentedon Jun 9, 2016
@pllim - ah yes, indeed! I'll fix that directly in master and will backport to 1.2.x
taldcroft commentedon Jun 9, 2016
@eteq @mhvk - argh. It did work when the PR was merged. Could the IERS-B update have had an impact? I'm investigating now.
taldcroft commentedon Jun 9, 2016
Oddly I get a failure in a slightly different place:
pllim commentedon Jun 9, 2016
I tested it in Python 2.7 with latest master, if it makes a difference.
taldcroft commentedon Jun 9, 2016
See #5051 for IERS fix.
astrofrog commentedon Jun 11, 2016
@pllim - can you confirm that everything is fixed on the latest master? (see #5072 which I think fixes the last of the remote tests)
pllim commentedon Jun 11, 2016
I can't test till Monday. If I'm holding up the release, just forge ahead. We can figure this out later if needed. Thanks!
pllim commentedon Jun 13, 2016
Yes, IERS tests finally pass. Thanks!
However, one Cone Search test is failing because some services are down (beyond my control) 😅 -- Do you want me to open a PR for this marking it as
xfailor something?eteq commentedon Jun 13, 2016
@pllim - hmm, I'm not currently getting that error, so my guess is that it's a transient one (unstable server). Might make sense to update the docstring to note that this particular test sometimes fails on the server-side... But in general we've been taking the view that it's better to have remote tests that fail sometimes for reasons outside our control than not have them get tested at all.
So I'd say we just leave the test as-is, and only
@mark.xfailor remove it if we can determine that it's definitely permanently down.Another option is to try to figure out how to recognize that the test failed due to a server problem, and then do an in-line
pytest.xfail()(although maybe that's what you meant now that I think about it?). But I've had lots of problems reliably catching those sort of errors, so I think it's not critical unless you can easily figure out how to do it.bsipocz commentedon Jun 13, 2016
@eteq - I think it's easy to measure the execution time of the lineall_results = ..., and if it's longer than the timeout xfail the test?Sorry for the noise, should have thought more about this before writing the comment as it's not a timeout issue...
pllim commentedon Jun 14, 2016
Okay, closing this now. We can open a new issue about Cone Search async test being unstable if needed. Thanks, everyone!