Remove node and id from list task response

[nik9000]

Right now the list tasks response returns both a node (string) and an id (number). The trouble is that everywhere else we refer to the task id as a string. The fact that the list tasks response has both of these elements implies some contract for the shape of a task id when we do not intend for there to be one. Currently the task id consists of the node, a :, and then the id but we might change it in the future without any prior warning.

I think we should remove node and id from the lists tasks response entirely and users should use the object's name in the response as the id.

This is what the response looks like now:

{
    "nodes": {
        "NCvmGYS-RsW2X8JxEYumgA": {
            "name": "NCvmGYS",
            "transport_address": "127.0.0.1:9300",
            "host": "127.0.0.1",
            "ip": "127.0.0.1:9300",
            "roles": [
                "master",
                "data",
                "ingest"
            ],
            "tasks": {
                "NCvmGYS-RsW2X8JxEYumgA:1204320": {
                    "node": "NCvmGYS-RsW2X8JxEYumgA",
                    "id": 1204320,
                    "type": "transport",
                    "action": "indices:data/write/delete/byquery",
                    "start_time_in_millis": 1528310404882,
                    "running_time_in_nanos": 24218556132,
                    "cancellable": true
                }
            }
        }
    }
}

And I want it to be:

{
    "nodes": {
        "NCvmGYS-RsW2X8JxEYumgA": {
            "name": "NCvmGYS",
            "transport_address": "127.0.0.1:9300",
            "host": "127.0.0.1",
            "ip": "127.0.0.1:9300",
            "roles": [
                "master",
                "data",
                "ingest"
            ],
            "tasks": {
                "NCvmGYS-RsW2X8JxEYumgA:1204320": {
                    "type": "transport",
                    "action": "indices:data/write/delete/byquery",
                    "start_time_in_millis": 1528310404882,
                    "running_time_in_nanos": 24218556132,
                    "cancellable": true
                }
            }
        }
    }
}

[elasticmachine]

Pinging @elastic/es-distributed

[diaojinggang]

When we designed the response format in the very beginning. Why don't we use a format like this? Give node_id and task_id proper keys.

{
    "nodes": [
         {  "node_id" : "NCvmGYS-RsW2X8JxEYumgA",
            "name": "NCvmGYS",
            "transport_address": "127.0.0.1:9300",
            "host": "127.0.0.1",
            "ip": "127.0.0.1:9300",
            "roles": [
                "master",
                "data",
                "ingest"
            ],
            "tasks": [
                {   "task_id": "NCvmGYS-RsW2X8JxEYumgA:1204320",
                    "type": "transport",
                    "action": "indices:data/write/delete/byquery",
                    "start_time_in_millis": 1528310404882,
                    "running_time_in_nanos": 24218556132,
                    "cancellable": true
                }
            ]
        }
    ]
}

My use case was I need to extract the task_id "NCvmGYS-RsW2X8JxEYumgA:1204320". But there is no key for `"NCvmGYS-RsW2X8JxEYumgA:1204320". It took me extra five minutes to figure out how to extract that info without a key-value pair format. It's not a big deal but I am curious why we did not use the key-value format when we designed it? Just to save space?

[nik9000]

The task id is meant to be an implementation detail. We can change how they are formed at any time so long as the old versions of Elasticsearch continue to route the task fetch requests to the right node. We have no plans to change it but we wanted to keep our options open.

[DaveCTurner]

I have marked this as team-discuss because I think it is a good idea and want to discuss with the team how we should approach this while preserving BWC.

[DaveCTurner]

We continue to think this is a good idea, but the BWC issues make it tricky right now. However, we are forming a more general plan around breaking changes to response formats like this, and think that this work will let us address exactly this issue. Marking this as stalled until that work lands.

[elasticsearchmachine]

Pinging @elastic/es-distributed (Team:Distributed)

[tlrx]

@DaveCTurner do you remember why we think it is a good idea? We discussed this issue in smaller group today and our feeling is that this issue gained not much attraction in the last year and introduces some breaking/compatibility work that is maybe not worth to effort given our future prioritized work. I'm tempted to close it for now.

[DaveCTurner]

do you remember why we think it is a good idea?

Users should treat task IDs as an opaque string such as NCvmGYS-RsW2X8JxEYumgA:1204320, and should avoid thinking about them as a node ID prepended onto some numeric value because we might want to change that format in future.

I'd think it would be ok to keep the node field (it makes sense to think about the node that's running a task) but we should drop the id field. Now that we have a versioned REST API I think we can do this fairly gracefully - only include the id field in API versions ≤8, but drop it in v9+.

[nik9000]

I'd think it would be ok to keep the node field (it makes sense to think about the node that's running a task) but we should drop the id field.

👍