search

AI-Planning / planning-as-a-service

The newly improved planner (and more) in the cloud.
Apache License 2.0
30 stars 7 forks source link

Inconsistent error reporting between planners #35

Open jan-dolejsi opened 2 years ago

jan-dolejsi commented 2 years ago

Here is how enhsp reports parsing errors: in the result.output.plan element:

{
  "call": "enhsp-2020 -o domain -f problem >> plan",
  "output": {
    "plan": "Domain parsed\nDistributor not found\n",
  },
  "output_type": "generic",
  "stderr": "bash: cannot set terminal process group (1): Inappropriate ioctl for device\nbash: no job control in this shell\n",
  "stdout": "",
}

Plus you may notice the stderr polluted by some unrelated internal errors.

The topk planner returns this json body:

{
  "Error": "Some error...."
}

...that is without the status or result element.

The status element should be mandatory in the returned payload.

haz commented 2 years ago

I'd like to start a discussion on the appropriate location of such an issue (and I agree, it's an issue worth fixing). If you check the call string, the enhsp-2020 planner just spits out the plan to stdout. There is no upper-level plan parser checking in on things, so it's an issue that resides either with PaaS (this repo), planutils (where the package is included), or with enhsp directly (if it even has a repo).

What are your thoughts on the appropriate location?

jan-dolejsi commented 2 years ago

If we are talking about plan parsing, and which component should have the responsibility...

Reading the description of the planutils repo "tools for developing, testing and validating", it belongs there. If there is interest, I have some Python code for parsing the plans and planner output in general.

But the issue is about consistency in error reporting. The OpenAPI description should standardize that.

haz commented 2 years ago

Ya, I think what this project (PaaS) can ensure is a stated "you must follow this spec if you want to be included in the online service" set of rules. For those packages that aren't destined for remote hosting by the official PaaS deploy, they're welcome to do whatever they'd like.