Only workflowrunner or also workflow runner?

[edeutsch]

Two questions:

1. What is the currently state of the workflow runner and ARS's interactions with it? Vague testing anecdotes seem to indicate that * if * an incoming query to ARS (or maybe ars-dev) includes workflow[ ], then it gets redirected to the workflow runner?

2. If true, this seems to be causing some issues with attempts to use the ARS because queries with workflows seem to yield responses that don't seem to be usable for reasons that are not completely clear. I'm wondering if during this testing phase it would be useful instead to send incoming queries that contain a workflow to all ARAs as well as the workflow runner?

This is prompted by the apparent observation that if we send a query with a workflow to the ARS (or ars-dev?) that we know ARAX can answer, it doesn't seem to get sent to ARAX, but somewhere else (workflow runner?) and we end up with no responses at all.

[kennethmorton]

I have recently inherited the workflow-runner from Patrick and I am actively developing. However, I don't think we should wait on my development speed to impact the ability of the ARS to answer workflows. Therefore, I think we should send workflows to applicable ARAs as well as the workflow-runner.

If you have an example workflow query that is giving you troubles I would appreciate an issue on the workflow-runner repo.

[edeutsch]

Great, thanks, this sounds good @kennethmorton .

@GregHydeDartmouth do you have that example query that had a workflow that we knew ARAX could handle but yielded nothing when sent to the ARS? Do I recall correctly that you had that example?

[GregHydeDartmouth]

@edeutsch Sorry for the late reply. Here is the query I was using earlier:

{
  "workflow": [
    {
      "id": "fill"
    },
    {
      "id": "bind"
    },
    {
      "id": "score"
    }
  ],
  "message": {
    "query_graph": {
      "edges": {
        "e0": {
          "constraints": [],
          "object": "n1",
          "predicates": [
            "biolink:related_to"
          ],
          "subject": "n0"
        },
        "e1": {
          "constraints": [],
          "object": "n2",
          "predicates": [
            "biolink:genetically_interacts_with"
          ],
          "subject": "n1"
        },
        "e2": {
          "constraints": [],
          "object": "n2",
          "predicates": [
            "biolink:affects",
            "biolink:correlated_with"
          ],
          "subject": "n3"
        },
        "e3": {
          "constraints": [],
          "object": "n4",
          "predicates": [
            "biolink:related_to"
          ],
          "subject": "n3"
        },
        "e4": {
          "constraints": [],
          "object": "n5",
          "predicates": [
            "biolink:related_to"
          ],
          "subject": "n2"
        }
      },
      "nodes": {
        "n0": {
          "categories": [
            "biolink:BiologicalProcess"
          ],
          "constraints": [],
          "ids": [
            "GO:0022010",
            "UMLS:C1818586"
          ],
          "is_set": false,
          "name": "central nervous system myelination"
        },
        "n1": {
          "categories": [
            "biolink:Gene",
            "biolink:Protein"
          ],
          "constraints": [],
          "is_set": true
        },
        "n2": {
          "categories": [
            "biolink:Gene",
            "biolink:Protein"
          ],
          "constraints": [],
          "is_set": true
        },
        "n3": {
          "categories": [
            "biolink:SmallMolecule"
          ],
          "constraints": [],
          "ids": [
            "CHEMBL.COMPOUND:CHEMBL134342",
            "CHEMBL.COMPOUND:CHEMBL1431",
            "CHEMBL.COMPOUND:CHEMBL573",
            "CHEMBL.COMPOUND:CHEMBL1626",
            "CHEMBL.COMPOUND:CHEMBL741",
            "CHEMBL.COMPOUND:CHEMBL1068",
            "CHEMBL.COMPOUND:CHEMBL1428",
            "CHEMBL.COMPOUND:CHEMBL30008"
          ],
          "is_set": false
        },
        "n4": {
          "categories": [
            "biolink:Disease"
          ],
          "constraints": [],
          "is_set": false
        },
        "n5": {
          "categories": [
            "biolink:Disease"
          ],
          "constraints": [],
          "is_set": false
        }
      }
    }
  }
}

When I send this to ars and open the link in ARAX UI I get https://arax.ncats.io/?r=d12e35a9-f6d6-4ca4-9efa-85d1c8f56eb0. Similarly for ars-dev I get https://arax.ncats.io/?r=33fdc270-e6db-463d-9ad1-f50c17361527. Which is strange because I'm used to opening up to a general response from all teams (or just the async teams when using ars-dev). Instead it looks like a team specific response to which there are no answers and only an approved trapi message. For the record when I pass the message directly to ARAX it appears to work fine. I'm sure you could use a much more simple query though (and I might do that instead as it will allow for faster testing). The goal of this workflow was to stop ARAX from using the normalized google distance to rank (i.e., by only allowing ARAs to fill, bind and score).

[kennethmorton]

Thanks. Investigating NCATSTranslator/workflow-runner#19