fix(cli): prepend task_id in ray list tasks output

[ngthkhanhha]

Description

This PR addresses the UX issue where task_id is hidden down in the default table fields. Moving task_id to the first position significantly improves readability when users check task statuses via the CLI.

Related issues

Fixes #30805

Additional information

• Tested manually by ensuring the column order format logic properly updates the header list.
• Minimal risk as it only modifies the CLI display presentation layer.

[gemini-code-assist]

Code Review

This pull request prepends "TASK_ID" to the table headers to improve the CLI user experience. The review feedback correctly points out that performing this list manipulation inside the row-processing loop is inefficient and suggests optimizing it by adjusting the column order once before entering the loop.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Modifying the headers list for every single row inside the loop is inefficient, especially when listing a large number of tasks (up to 10,000).

Instead, it is much more efficient to adjust the column order in cols once before entering the loop (around line 185). This avoids redundant list search, removal, and insertion operations for every row in state_data.

You can remove this block inside the loop and place the following logic right after cols = schema.list_columns(detail=detail):

cols = schema.list_columns(detail=detail)
if "task_id" in cols:
    cols.remove("task_id")
    cols.insert(0, "task_id")

[edoakes]

Agreed ^^^

The current solution is a bit hacky. Ideally we would define the column order directly in the StateSchema subclass somehow

[github-actions]

This pull request has been automatically marked as stale because it has not had
any activity for 14 days. It will be closed in another 14 days if no further activity occurs.
Thank you for your contributions.

You can always ask for help on our discussion forum or Ray's public slack channel.

If you'd like to keep this open, just leave any comment, and the stale label will be removed.

[martinlhw]

Thanks for the contribution. I agree with @edoakes's comment about reordering the column names in the relevant schema dataclass.

[KuongB]

Hi @martinlhw, I see #64283 is stalled and you've self-assigned this. I'd like to take the column-ordering part (checkbox 2) following @edoakes's suggestion to define ordering in the schema itself. Are you already working on it? Happy to take it if not.

[martinlhw]

Hi @KuongB, I'm not working on it, so please feel free to take a stab on it. We might want to check on if @ngthkhanhha is working on it or not.

[KuongB]

Hi @ngthkhanhha — thanks for surfacing this one, your PR is what got me digging into it.

Following @edoakes' and @martinlhw 's suggestion about defining the order in StateSchema, I opened #65052. While looking into it I found that list_columns() already returns the columns in schema order, and that the CLI output is correct today — the actual bug is in filter_fields(), which iterates over a set and so gives the State API a key order that depends on the process hash seed.