cylc-uiserver icon indicating copy to clipboard operation
cylc-uiserver copied to clipboard

Different results for the same stop mutation

Open kinow opened this issue 3 years ago • 3 comments

Describe the bug

Some really strange behaviour in GraphiQL & UIS when testing the following mutation.

mutation {
  stop (workflows: ["user|cylc"]) { # <---- INVALID WORKFLOW ID
    result
  }
}

It returns different results, and a incorrectly displayed error message, but it depends on when you execute the query?

Release version(s) and/or repository branch(es) affected?

master everywhere.

Steps to reproduce the bug

  1. Start UIS, don't run any workflows, run the mutation in GraphiQL. Reply (in less than 1 second):
{
  "data": {
    "stop": {
      "result": []
    }
  }
}
  1. Start five. Run the exact mutation (i.e. don't change the workflow ID). Reply (again, less than 1 second):
{
  "data": {
    "stop": {
      "result": [
        "E",
        "r",
        "r",
        "o",
        "r",
        ":",
        " ",
        "N",
        "o",
        " ",
        "m",
        "a",
        "t",
        "c",
        "h",
        "i",
        "n",
        "g",
        " ",
        "W",
        "o",
        "r",
        "k",
        "f",
        "l",
        "o",
        "w"
      ]
    }
  }
}
  1. It gets stranger. Now stop five and run the exact mutation yet again really fast! Don't wait too long! Reply (in ~2 seconds):
{
  "errors": [
    {
      "message": "'NoneType' object has no attribute 'values'",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [
        "stop",
        "result"
      ]
    }
  ],
  "data": {
    "stop": {
      "result": null
    }
  }
}

This error is similar to the error from: https://github.com/cylc/cylc-uiserver/issues/242 4. Oh, one more scenario. Instead of stopping and executing the GraphQL immediately, if you instead wait a few seconds after you stopped five, then you get the first reply again (<1 sec):

{
  "data": {
    "stop": {
      "result": []
    }
  }
}

😵 any idea what could be wrong? Looks like there's some state in the UIS or flow that is not going well with the resolvers?

Expected behavior

Consistent responses, in a way that a user/dev would expect them to happen.

Screenshots

Additional context

Asked @dwsutherland over Element about it.

Pull requests welcome! This is an Open Source project - please consider contributing a bug fix yourself (please read CONTRIBUTING.md before starting any work though).

kinow avatar Sep 14 '21 23:09 kinow