[Refactor][history server] align timeline conventions with Ray Dashboard

[AndySung320]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

Background

While working on the task timeline implementation, we noticed a few places where our code diverges slightly from Ray Dashboard conventions, or could be made more consistent / maintainable.

These are minor issues individually, but they all relate to alignment with Ray’s existing dashboard behavior, so I’d like to track them together as a small refactor.

Related PR : #4437

---

1. Extract task:: prefix into a constant

The string prefix task:: is currently hard-coded in multiple places.

Proposal

• Extract it into a shared constant (e.g. TaskPrefix or similar)
• Use the constant everywhere we match or generate task category names

Motivation

• Avoid magic strings
• Make future changes safer and more discoverable

---

2. PID / TID assignment consistency with Ray Dashboard

Currently:

• PID and TID are generated locally using counters (0, 1, 2, …) rather than read from Ray events
• This is intentional, since Ray task profile events do not include pid or tid
• Ray Dashboard does the same in chrome_tracing_dump() (ray/_private/profiling.py)

However, there is one difference:

• Ray Dashboard assigns globally unique TIDs
• Our current Go implementation assigns TIDs per node

Proposal

• we can refactor the TID assignment logic to follow the same approach as Ray’s implementation

This is a minor difference, but aligning fully with Ray Dashboard may reduce surprises when comparing timelines.

---

3. Rename structs with DTO suffix

Several structs currently include the DTO suffix, but they directly represent
the Ray Event Export API JSON payloads and are not used as transfer objects
between architectural layers.

Proposal

• Rename these structs to remove the DTO suffix (e.g. TaskProfileEventDTO → TaskProfileEvent)
• Keep the structure and behavior unchanged; this is a naming-only refactor

Motivation

• These types are 1:1 mappings of the Ray Event Export API schema, not generic Data Transfer Objects
• The DTO suffix does not add meaningful clarity in this context
• Renaming it improves readability and avoids confusion about their role in the codebase

---

Use case

No response

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!