Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Agent query endpoint not TRAPI compliant #52

Closed
southalln opened this issue Sep 26, 2020 · 7 comments
Closed

Improve Agent query endpoint not TRAPI compliant #52

southalln opened this issue Sep 26, 2020 · 7 comments
Assignees
Milestone

Comments

@southalln
Copy link
Contributor

southalln commented Sep 26, 2020

One of the test queries we currently use to probe service status is a one-hop query, and this is currently returning a non-status 200 response for improve agent. We have yet to fully converge on a standard for error responses from Reasoner API services, but the current convention is to return a status 200 response if the message was received and is TRAPI compliant. See, for example, NCATSTranslator/ReasonerAPI#140

@southalln
Copy link
Contributor Author

southalln commented Sep 26, 2020

@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
Copy link
Contributor

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
Copy link
Collaborator

@MarkDWilliams MarkDWilliams changed the title Improve Agent returns "method not allowed" Improve Agent query endpoint not TRAPI compliant Dec 1, 2020
@sstemann sstemann added this to the 1.0 milestone Dec 1, 2020
@sstemann
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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"
}
  1. 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
Copy link
Contributor

sstemann commented Feb 9, 2021

registration is completed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants