feat: Add manual long task reporting API.#319
Conversation
Long tasks are periods in the application that stall the main thread for a specific length of time. While we can't automatically detect these in the C++ SDK, we need to provide a way for clients (including other SDKs) to manually report them. The C++ SDK takes a long task duration in Nanoseconds (following the Android SDK as an example) and sends a Long Task event to RUM. Additionally, View and Action scopes keep track of the number of Long Tasks that occur in their scope, and forward this information over to RUM when those events are sent. refs: RUM-17248
fuzzybinary
changed the title
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 67117400a3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (command.Is<RumAddLongTaskPayload>()) { | ||
| _num_long_tasks_recorded++; |
There was a problem hiding this comment.
When a long task is reported after a discrete action's 100 ms timeout—for example AddAction at T=0, a task starts at T=5 ms and lasts 800 ms, and AddLongTask is called at T=805 ms—the action scope closes in the earlier expiration path and returns before this new AddLongTask block runs. The long-task event is then emitted without action.id, and the action event lacks action.long_task.count, even though SendLongTaskEvent backdates the event to the task start, so frozen frames caused by user actions are not correlated.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
A good callout, but likely will remain a gap in our functionality. We can't keep Actions around forever hoping to see a Long Task after the action event has expired.
This Gap likely also exists in other SDKs.
| * provided as an Attribute with ValueType::Object. | ||
| */ | ||
| DATADOG_API void AddLongTask( | ||
| uint64_t duration_ns, const Attribute& attributes = Attribute() |
There was a problem hiding this comment.
FWIW we expose a datadog::Duration (which is just an alias for std::chrono::nanoseconds) in the C++ API, which would give us stricter type safety and convenient conversion from other std::chrono formats.
That said, I'm totally fine with just using uint64_t here for the sake of simplicity.
There was a problem hiding this comment.
Completely your call here. I feel like uint64_t might be more convenient for clients, but datadog::Duration is definitely the safer option.
Just say the word and I'l change it over.
2 participants
refs: RUM-17275
Long tasks are periods in the application that stall the main thread for a specific length of time. While we can't automatically detect these in the C++ SDK, we need to provide a way for clients (including other SDKs) to manually report them.
The C++ SDK takes a long task duration in Nanoseconds (following the Android SDK as an example) and sends a Long Task event to RUM. Additionally, View and Action scopes keep track of the number of Long Tasks that occur in their scope, and forward this information over to RUM when those events are sent.