Federated query with PREFIX statements fails on some conditions #140
Description
Issue Description:
Federated query with PREFIX statements fails on some conditions (in my case, when one of the federated endpoints replies with more than 6 triples):
2023-09-29 10:49:17 INFO query.ProviderService.getTimeout:919 [] - Timeout: 10000
2023-09-29 10:49:17 INFO load.Service.basicPost:253 [] - Post http://10.112.17.134:8078/query
2023-09-29 10:49:17 INFO load.Service.basicPost:286 [] - Response status: 400
2023-09-29 10:49:17 ERROR load.Service.basicPost:318 [] - http://10.112.17.134:8078/query
2023-09-29 10:49:17 ERROR load.Service.basicPost:319 [] - jakarta.ws.rs.client.ResponseProcessingException error at 13:52: expected UNDEF
2023-09-29 10:49:17 ERROR query.ProviderService.exception:507 [] - jakarta.ws.rs.client.ResponseProcessingException http://10.112.17.134:8078/query
2023-09-29 10:49:17 ERROR query.ProviderService.error:596 [] - service error: http://10.112.17.134:8078/query
2023-09-29 10:49:17 ERROR query.ProviderService.error:600 [] - error at 13:52: expected UNDEF
2023-09-29 10:49:17 ERROR query.ProviderService.error:602 [] -
prefix network: <http://example.com/network.owl#>
prefix ex: <http://example2.com/ns#>
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
select *
where {
?device network:hasVrf ?vrf .
?device rdf:type network:Device .
?vrf network:hasInterfaceVrf ?intf .
}
limit 1000
2023-09-29 10:49:17 INFO query.ProviderService.submitError:612 [] - Blacklist: http://10.112.17.134:8078/query 1
The query works as expected without PREFIX and full URIs.
Bug Details:
We intercepted query from the corese to one of the federated endpoints and noticed inconsistency: mixed prefix and URI statements, leading to HTTP 400 error from the federated endpoint.
query=prefix+network:+<http://example.com/network.owl#>
prefix+ex:+<http://example2.com/ns#>
prefix+rdf:+<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
select+*+
where+{
++values+(?intf+){
++++(<http://example.com/network.owl#SS1-DRDC-111-000_Port-channel151.10>+)
++++(<http://example.com/network.owl#SS1-DRDC-111-000_Port-channel152.20>+)
++++(network:SS1-DRDC-111-000_Vlan3920+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_Bundle-Ether31.10>+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_Bundle-Ether32.20>+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_Bundle-Ether100.2301>+)
++++(network:SD-0MSK-MAR4-001_GigabitEthernet0/0/0/1+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_TenGigE0/0/0/13.3054>+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_TenGigE0/0/0/13.3332>+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_Bundle-Ether100.433>+)
++}
++?device+network:hasVrf+?vrf+.
++?device+rdf:type+network:Device+.
++?vrf+network:hasInterfaceVrf+?intf+.
}
limit+1000+
The error does not occur on federating small graphs (up to 6 triples in our case). The error occurs when one of the federated endpoints replies with more than 6 triples.
Steps to Reproduce:
- Set up corese federation as described in Distributed query process is (or seems to be) missing #138
- Roll out two SPARQL endpoints for federation: SPARQL endpoint for RDFLib and Oxigraph
- Query ../federate endpoint provided by the corese
Expected Behavior:
Federated query returns results.
Actual Behavior:
SPARQL endpoint for RDFLib returns HTTP 400 error on query from the corese (probably because of mixed prefix and URI statements).
Note to Developers:
None
Screenshots/Attachments:
None