Hostname not resolved when using docker service alias in spec string with server.openSession

[kysrpex]

While working with agraph-python, I experienced an issue that might be a bug in agraph-python itself.

I am running the v7.0.4 version of the franzinc/agraph Docker image in a CI machine through GitLab-runner. The relevant part of the file GitLab-ci configuration file looks like this.

variables:
  AGRAPH_SUPER_USER: "XXX"
  AGRAPH_SUPER_PASSWORD: "YYY"
  AGRAPH_USER: "XXX" (same as super-user)
  AGRAPH_PASSWORD: "YYY" (same as super-password)
  AGRAPH_PORT: 10035
  AGRAPH_HOST: "db"

services:
  - name: franzinc/agraph:v7.0.4
    alias: db

The important thing to note is that the agraph image was given the alias db.

At a certain point, I am trying to reuse the spec string of two existing franz.openrdf.repository.repositoryconnection.RepositoryConnection objects, to perform a federated SPARQL query. self._server is an AllegroGraphServer object, created with the same username, password and host arguments as self._ontology_engine and self._engine, which are RepositoryConnection objects, created with ag_connect, which are working.

[...]
            context = self._ontology_engine.createURI(
                f'http://www.osp-core.com/agraph_session_id#'
                f'{self._session_id}')
            spec_ontology = spec.graphFilter(self._ontology_engine.getSpec(),
                                             [context])
            spec_engine = self._engine.getSpec()
            spec_federated = spec.federate(spec_ontology, spec_engine)
            query_engine = self._server.openSession(spec_federated)

        tuple_query = query_engine.prepareTupleQuery(
            QueryLanguage.SPARQL, query_string)
[...]

After that, I call tuple_query.evaluate() and get the following error:

[...]
[...] line 270, in _sparql (the code pasted above)
    query_engine = self._server.openSession(spec_federated)
  File "/usr/local/lib/python3.7/site-packages/agraph_python-101.0.7-py3.7.egg/franz/openrdf/sail/allegrographserver.py", line 243, in openSession
    minirep = self._client.openSession(spec, autocommit=autocommit, lifetime=lifetime, loadinitfile=loadinitfile)
  File "/usr/local/lib/python3.7/site-packages/agraph_python-101.0.7-py3.7.egg/franz/miniclient/repository.py", line 192, in openSession
    loadInitFile=loadinitfile, store=spec))
  File "/usr/local/lib/python3.7/site-packages/agraph_python-101.0.7-py3.7.egg/franz/miniclient/request.py", line 99, in jsonRequest
    else: raise RequestError(status, body)
franz.miniclient.request.RequestError: Server returned 400: Failed to start a session with specification <db:simphony-ontologies>{<http://www.osp-core.com/agraph_session_id#4a797b0c-35b0-4781-bb82-638ad417e297>}+<db:test_osp_core_transfer>:
Unknown hostname: "db"

Actually, the spec_federated string is not exactly as the RequestError reports, the value is: <http://XXX:YYY@db:10035/repositories/simphony-ontologies>{<http://www.osp-core.com/agraph_session_id#1e444591-b5d9-4e9a-80c3-b0566ee85074>} + <http://XXX:YYY@db:10035/repositories/test_osp_core_transfer>.

I thought this did not make much sense, so I just tried resolving the host name with the sockets library and replacing the IP in the spec string.

[...]
            context = self._ontology_engine.createURI(
                f'http://www.osp-core.com/agraph_session_id#'
                f'{self._session_id}')
            spec_ontology = spec.graphFilter(self._ontology_engine.getSpec(),
                                             [context])
            spec_engine = self._engine.getSpec()
            spec_federated = spec.federate(spec_ontology, spec_engine)
            ip = socket.gethostbyname("db")
            spec_federated = spec_federated.replace('db', ip)
            query_engine = self._server.openSession(spec_federated)

        tuple_query = query_engine.prepareTupleQuery(
            QueryLanguage.SPARQL, query_string)
[...]

Surprisingly, after this change tuple_query.evaluate() works as expected, and the results of the query are correct. In the end I just worked around the issue by writing a function that resolves all host names in a spec string and replaces them.

Let me know if you need more information to locate the source of the problem.

[divaricatum]

I looked at this report a while ago and I guess I misread it to say you had solved the problem. I now see you just found a workaround. I gather the problem is with the spec.federate function. Any additional information you have would be helpful. You can post it here or send it to [email protected] referencing spr45420.
David Margolies, Franz Inc.