Remove useless statement in task_group_to_grid

[pierrejeambrun]

This PR just removes a statement that had no effect.

We keep sending possibly 'None' state in the grid data except for the 'mapped_states' count. (None keys in json are an issue)

I have another version of this PR here, where instead, None status are changed to 'no_status' in the entire returned payload. I don't think this is a good idea because either way the front will still have to handle None state. (Other endpoints returning TaskInstance will not do this transformation).

I plan to work on grid_data endpoint to make it return object following the api_connexion.TaskInstance schema. (run_id vs dag_run_id and other differences), to be able to unify those types in the front. (They are not playing nice with each other atm)

[ashb]

I plan to work on grid_data endpoint follow the api_connexion.TaskInstance schema. (run_id vs dag_run_id and other differences), to be able to unify those types in the front. (They are not playing nice with each other right now)

So the grid_data endpoint is "private"/"internal" which means the format of the data it returns should be tailored to exactly what the UI needs, and not generic like the OpenAPI REST API. So only change the format if it makes the UI cleaner (don't just do it for the sake of it in other words)

[bbovenzi]

So the grid_data endpoint is "private"/"internal" which means the format of the data it returns should be tailored to exactly what the UI needs, and not generic like the OpenAPI REST API. So only change the format if it makes the UI cleaner (don't just do it for the sake of it in other words)

Yeah, that's the plan. There's some inconsistencies between the task instances in the internal grid_data and the REST get_mapped_instances. This causes some issues in the UI code. That's what Pierre wants to fix.

[pierrejeambrun]

Understood @ashb, thanks for the details :). Yes the main reason here is to avoid manual object conversion and casting in the UI code.