[FR] Enhance `task_id` methods UX

[smk762]

I was recently overjoyed to find out there was a forget_if_finished param for task::xxxx::status methods. If it is not too much overhead, can we please make this false by default?

Here's couple more ideas for ways to make checking in on previous tasks a bit simpler.

• add a method like view_tasks which takes no params, but returns a dict of previous/current/tasks like

  [
  {
   "task_id": 0,
   "status_method": "task::enable_z_coin::status",
   "completed": true
  },
  {
   "task_id": 1,
   "status_method": "task::withdraw::status",
   "completed": false
  }
  ]

  completed key/value can be omitted to reduce overhead, task_id and status_method is enough to make targeted query as needed.

• Alternatively, a single unified task::status method which has awareness of which type of query/response is expected from a given task_id input value. e.g.

  curl --url "$url:$port" --data "{
  \"mmrpc\":\"2.0\",
  \"userpass\":\"$userpass\",
  \"method\":\"task::status\",
  \"params\": {
      \"task_id\": 1
  }
  ,\"id\":0
  }"

[sergeyboyko0791]

Good ideas! We can definitely work in this direction

[artemii235]

Alternatively, a single unified task::status method which has awareness of which type of query/response is expected from a given task_id input value. e.g.

Won't it be confusing if a single RPC can respond with dozens (if not hundreds) of different data structures? Is it feasible to support this in GUIs?

[smk762]

Without a method which lists the tasks by id, it would be confusing. The unified method is optional, essentially just a wrapper around the others which would internally reference the ID : task list. For GUI, the ID : task list is enough to know which actual method to use for status query.

[sergeyboyko0791]

I though @smk762 meant to return IDs of the tasks, not the task data.

Won't it be confusing if a single RPC can respond with dozens (if not hundreds) of different data structures?

In addition to the initial question, it would be difficult to return the list of different tasks such as task::enable_z_coin::status and task::withdraw::status. But I believe we could return multiple statuses for the same RPC method. For example,

curl --url "$url:$port" --data "{
    \"mmrpc\":\"2.0\",
    \"userpass\":\"$userpass\",
    \"method\":\"task::withdraw::status\",
    \"params\": {
        \"all\": true
    }
    ,\"id\":0
}"

And response:

[
  {
     "task_id": 1,
     "completed": false
  },
  {
     "task_id": 3,
     "completed": true
  }
]

In this case we'll even be able to return the status payload as all of the tasks have the same response structure. For example, task::init_trezor::status results:

[
  {
    "task_id": 1,
    "status": "Error", 
    "details": {
      "error": "No Trezor device available",
      "error_type": "HwError"
    }
  },
  {
    "task_id": 3,
    "status": "UserActionRequired",
    "details": "EnterTrezorPin"
  }
]