Improve Agent query endpoint not TRAPI compliant about relay

[southalln]

@brettasmi Here is an example of the test query and some details of the POST response we are currently getting.

{
  "model": "tr_ars.message",
  "pk": "0865aef7-4051-4268-8ced-6b08b20adad4",
  "fields": {
    "name": "",
    "code": 405,
    "status": "Error",
    "actor": 11,
    "timestamp": "2020-09-26T09:59:50.103Z",
    "data": {
      "message": {
        "query_graph": {
          "edges": [
            {
              "id": "e00",
              "source_id": "n00",
              "target_id": "n01",
              "type": "treated_by"
            }
          ],
          "nodes": [
            {
              "curie": "MONDO:0021668",
              "id": "n00",
              "type": "disease"
            },
            {
              "id": "n01",
              "type": "chemical_substance"
            }
          ]
        }
      },
      "callback": "http://localhost:8000/ars/api/messages/0865aef7-4051-4268-8ced-6b08b20adad4",
      "logs": [
        "{\n  "detail": "The method is not allowed for the requested URL.",\n  "status": 405,\n  "title": "Method Not Allowed",\n  "type": "about:blank"\n}\n",
        "Tr_ars.server: nginx/1.16.1",
        "Tr_ars.date: Sat, 26 Sep 2020 09:59:50 GMT",
        "Tr_ars.content-Type: application/problem+json",
        "Tr_ars.content-Length: 142",
        "Tr_ars.connection: keep-alive",
        "Tr_ars.reason: METHOD NOT ALLOWED",
        "Tr_ars.url: https://evidara.healthdatascience.cloud/api/v1/query"
      ]
    },
    "url": "https://evidara.healthdatascience.cloud/api/v1/query",
    "ref": "2c6ec0f1-5fd1-4ed8-b185-1add781f888f"
  }
}

[brettasmi]

Thanks for the report Noel. I will try to recreate the issue locally and fix it. A quick glance suggests that query should be returning a 200 without results.

[MarkDWilliams]

suihuanglab/improving-agent#20

[sstemann]

based on the ARS call today, (im)Prove is compliant, but there is an error like "method is not allowed" when a TRAPI query is sent from the ARS. When it is sent directly, (im)Prove works fine.

[brettasmi]

From the logs, I can see that there seems to be an unexpected callback arg during deserialization of the Query object.

It would be helpful to see the query that you are attempting to make so that I can try to reproduce it.

Also, see https://github.com/suihuanglab/improving-agent/blob/main/examples/improving_agent_examples.ipynb for working TRAPI 1.0 examples

[brettasmi]

After some debugging with Mark yesterday, we discovered a couple things:

1. Mark is able to hit imProving Agent manually via requests and the local dev instance of the ARS. However, the ARS queries were still failing on the callback key that isn't in the strict TRAPI spec. I've made some changes to accommodate that on our end. I can confirm that the following test query now is now processed by imProving Agent:

{
  "message": {
    "query_graph": {
      "nodes": {
        "n00": { "id": "MONDO:0018150", "category": "biolink:Disease" },
        "n01": { "category": "biolink:ChemicalSubstance" }
      },
      "edges": { "e00": { "subject": "n00", "object": "n01" } }
    }
  },
  "callback": "http://localhost:8000/ars/api/messages/8167a94e-6194-4706-8c84-2f69ad381035"
}

2. the 405 remains from the production ARS. I've noticed that this is presenting symptoms similar to what I've seen when I accidentally call the http version of the query url. I see a 301 redirect in the nginx logs which converts the POST to a GET for uWSGI, which then returns a 405 Could something be wrong with the production ARS's TLS/SSL config?

[sstemann]

registration is completed