[observability][export-api] Write task events #47193

nikitavemuri · 2024-08-19T00:23:39Z

Why are these changes needed?

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false.
All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well.
- The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush.
Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second).
Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file.

Related issue number

Checks

I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
I've run scripts/format.sh to lint the changes in this PR.
I've included any doc changes needed for https://docs.ray.io/en/master/.
- I've added any new APIs to the API Reference. For example, if I added a
  method in Tune, I've added it in doc/source/tune/api/ under the
  corresponding .rst file.
I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
Testing Strategy
- Unit tests
- Release tests
- This PR is not tested :(

Signed-off-by: Nikita Vemuri <[email protected]>

nikitavemuri · 2024-08-19T00:24:50Z

src/ray/util/event.cc

@@ -180,7 +180,9 @@ EventManager &EventManager::Instance() {
  return instance_;
 }

-bool EventManager::IsEmpty() { return reporter_map_.empty(); }
+bool EventManager::IsEmpty() {
+  return reporter_map_.empty() && export_log_reporter_map_.empty();


Followup from #47143

Signed-off-by: Nikita Vemuri <[email protected]>

nikitavemuri · 2024-08-19T06:33:40Z

src/ray/util/event.cc

-        << ExportEvent_SourceType_Name(export_event.source_type())
-        << ". This indicates a bug in the code, and the event will be dropped.";
-  }
+  RAY_CHECK(element != export_log_reporter_map_.end());


Followup from #47143

Signed-off-by: Nikita Vemuri <[email protected]>

…ita/write_task_events

rkooo567

Btw, I am not 100% sure if it is a good idea to aggregate events ourselves because it means we will have indeterministic data in the log depending on when we flush. But I wil just let it go for now (we should definitely talk to customers if it is semantic they want)

rkooo567 · 2024-08-20T22:46:26Z

src/ray/gcs/pb_util.h

+/// Convert rpc::TaskLogInfo to rpc::ExportTaskEventData::TaskLogInfo
+inline void TaskLogInfoToExport(const rpc::TaskLogInfo &src,
+                                rpc::ExportTaskEventData::TaskLogInfo *dest) {
+  dest->set_stdout_file(src.stdout_file());


QQ: can we just swap here? Is the caller still using src after it is passed?

dest->Swap(&src)

This function is called with src being state_update_->task_log_info_.value() so we probably shouldn't change src because it's a TaskStatusEvent class attribute

rkooo567 · 2024-08-20T22:46:37Z

src/ray/gcs/pb_util.h

+    int64_t timestamp,
+    rpc::ExportTaskEventData::TaskStateUpdate *state_updates) {
+  if (task_status == rpc::TaskStatus::NIL) {
+    // Not status change.


Suggested change

// Not status change.

// No status change.

Qq; when does it happen?

Looks like NIL is the default value when a TaskStatusEvent is initialized. @rickyyx Do you know if FillTaskStatusUpdateTime is ever called when the task_status = rpc::TaskStatus::NIL? This logic is mirrored from that function

rkooo567 · 2024-08-20T23:26:59Z

src/ray/core_worker/task_event_buffer.cc

@@ -211,6 +289,7 @@ bool TaskEventBufferImpl::Enabled() const { return enabled_; }

 void TaskEventBufferImpl::GetTaskStatusEventsToSend(
    std::vector<std::unique_ptr<TaskEvent>> *status_events_to_send,
+    std::vector<std::unique_ptr<TaskEvent>> *dropped_status_events_to_write,


Instead of maintaining dropped tasks, can we just maintain a new vector just for export events? And we can just make it 10X original vector. I think maintaining another dropped tasks that are not dropped is not intuitive + it can easily screw up ordering depending on task drop policy.

Sounds good. I needed to make the buffers for these events contain a shared_ptr rather than unique_ptr though so the same object can be moved to multiple buffers.

also can you just run microbenchmark to see if there's any noticeable regression (I think it shouldn't affect but just in case)? lmk if you don't know how to run them!

yes, ran in https://buildkite.com/ray-project/release/builds/21683

nikitavemuri · 2024-08-21T09:18:24Z

Btw, I am not 100% sure if it is a good idea to aggregate events ourselves because it means we will have indeterministic data in the log depending on when we flush.

Makes sense, we can revisit this logic after this initial prototype. The tradeoff here is minimizing the number of events that get written

Signed-off-by: Nikita Vemuri <[email protected]>

rkooo567 · 2024-08-28T20:00:08Z

okay, microbenhcmark result looks good. is this PR ready to review again
?

nikitavemuri · 2024-08-28T20:02:14Z

okay, microbenhcmark result looks good. is this PR ready to review again ?

yes

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Write task events to file as part of the export API. This logic is only run if RayConfig::instance().enable_export_api_write() is true. Default value is false. All tasks that are added to the task event buffer will be written to file. In addition, keep a dropped_status_events_for_export_ buffer which stores status events that were dropped from the buffer to send to GCS, and write these dropped events to file as well. The size of dropped_status_events_for_export_ is 10x larger than task_events_max_num_status_events_buffer_on_worker to prioritize recording data. The tradeoff here is memory on each worker, but this is a relatively small overhead, and it is unlikely the dropped events buffer will fill given the sink for export events (write to file) will succeed on each flush. Task events converted to the export API proto and written to file in a separate thread, which runs this flush operation periodically (every second). Individual task events will be aggregated by task attempt before being written. This is consistent with the final event sent to GCS, and also helps reduce the number of events written to file. Signed-off-by: ujjawal-khare <[email protected]>

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

- Re add code changes from [observability][export-api] Write task events ray-project#47193, which was previous reverted due to CI test linux://:task_event_buffer_test is consistently_failing ray-project#47519, CI test windows://:task_event_buffer_test is consistently_failing ray-project#47523 and CI test darwin://:task_event_buffer_test is consistently_failing ray-project#47525 - Was able to reproduce the failures locally and fixed test in 07efa6f. Failure was due to logical merge conflict (previous PR wasn't re-based off latest master after other event PRs were merged). Signed-off-by: Nikita Vemuri <[email protected]> Co-authored-by: Nikita Vemuri <[email protected]> Signed-off-by: ujjawal-khare <[email protected]>

Nikita Vemuri added 7 commits August 16, 2024 16:37

wip

c583c1f

Signed-off-by: Nikita Vemuri <[email protected]>

wip - manual testing

a08d9c8

Signed-off-by: Nikita Vemuri <[email protected]>

fix test

7b98465

Signed-off-by: Nikita Vemuri <[email protected]>

add ff

9100b95

Signed-off-by: Nikita Vemuri <[email protected]>

add metrics

143e339

Signed-off-by: Nikita Vemuri <[email protected]>

remove debug

8789305

Signed-off-by: Nikita Vemuri <[email protected]>

formatting

19419a8

Signed-off-by: Nikita Vemuri <[email protected]>

nikitavemuri commented Aug 19, 2024

View reviewed changes

add followup

95cd535

Signed-off-by: Nikita Vemuri <[email protected]>

nikitavemuri commented Aug 19, 2024

View reviewed changes

add comment

e0a1946

Signed-off-by: Nikita Vemuri <[email protected]>

nikitavemuri added the go add ONLY when ready to merge, run all tests label Aug 19, 2024

fix test

24e925b

Signed-off-by: Nikita Vemuri <[email protected]>

nikitavemuri marked this pull request as ready for review August 19, 2024 17:08

nikitavemuri requested a review from a team as a code owner August 19, 2024 17:08

nikitavemuri requested a review from rkooo567 August 19, 2024 17:09

Merge branch 'master' of https://github.com/nikitavemuri/ray into nik…

6f4126a

…ita/write_task_events

rkooo567 self-assigned this Aug 20, 2024

rkooo567 reviewed Aug 20, 2024

View reviewed changes

rkooo567 added the @author-action-required The PR author is responsible for the next step. Remove tag to send back to the reviewer. label Aug 20, 2024

Nikita Vemuri added 7 commits August 21, 2024 22:28

wip - convert to shared_ptr

2611de7

Signed-off-by: Nikita Vemuri <[email protected]>

wip - tests pass

6573fe5

Signed-off-by: Nikita Vemuri <[email protected]>

update

c26b5a0

Signed-off-by: Nikita Vemuri <[email protected]>

update

c7518c4

Signed-off-by: Nikita Vemuri <[email protected]>

formatting

906ed21

Signed-off-by: Nikita Vemuri <[email protected]>

run tests

4f35176

Signed-off-by: Nikita Vemuri <[email protected]>

run tests

9ae4a99

Signed-off-by: Nikita Vemuri <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

0ff57ca

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

2a08cc6

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

46b8ccb

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

80f95d6

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

ed94e0e

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

3dca501

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

aa4b2a8

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

a9a0402

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

623ffab

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

ujjawal-khare pushed a commit to ujjawal-khare-27/ray that referenced this pull request Oct 15, 2024

Revert "[observability][export-api] Write task events" (ray-project#4…

950ad18

…7536) Reverts ray-project#47193 Signed-off-by: ujjawal-khare <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[observability][export-api] Write task events #47193

[observability][export-api] Write task events #47193

nikitavemuri commented Aug 19, 2024 •

edited

Loading

nikitavemuri Aug 19, 2024

nikitavemuri Aug 19, 2024

rkooo567 left a comment

rkooo567 Aug 20, 2024

nikitavemuri Aug 21, 2024

rkooo567 Aug 20, 2024

rkooo567 Aug 20, 2024

nikitavemuri Aug 21, 2024

rkooo567 Aug 20, 2024

nikitavemuri Aug 23, 2024

rkooo567 Aug 23, 2024 •

edited

Loading

nikitavemuri Aug 27, 2024

nikitavemuri commented Aug 21, 2024

rkooo567 commented Aug 28, 2024

nikitavemuri commented Aug 28, 2024

[observability][export-api] Write task events #47193

[observability][export-api] Write task events #47193

Conversation

nikitavemuri commented Aug 19, 2024 • edited Loading

Why are these changes needed?

Related issue number

Checks

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkooo567 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rkooo567 Aug 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikitavemuri commented Aug 21, 2024

rkooo567 commented Aug 28, 2024

nikitavemuri commented Aug 28, 2024

nikitavemuri commented Aug 19, 2024 •

edited

Loading

rkooo567 Aug 23, 2024 •

edited

Loading