Wimmics/corese

Federated query with PREFIX statements fails on some conditions

tokarenko opened this issue · 3 comments

tokarenko commented

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:

  1. Set up corese federation as described in #138
  2. Roll out two SPARQL endpoints for federation: SPARQL endpoint for RDFLib and Oxigraph
  3. 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

ocorby commented
remiceres commented

Thank you for the report. I've made the necessary changes in the code. The fix will be included in the next release. If you'd like to access the modifications immediately, you can compile them from the source in the development branch.

tokarenko commented

Thank you @ocorby , @remiceres for providing the patch and including it into upcoming version. I will wait for the new version to test it.