[core] Fix crash when killing actor handle from previous session #59425

kriyanshii · 2025-12-14T10:00:06Z

Fixes the issue where the interpreter would crash instead of providing a useful error message.

Description

Previously, calling ray.kill() on an ActorHandle from a previous Ray session (after ray.shutdown() and ray.init()) would crash the Python interpreter with a C++ assertion failure.

This fix:

Prevents the crash by only calling OnActorKilled() in C++ when the kill operation succeeds
Catches the error in Python and converts it to a helpful ValueError explaining that ActorHandle objects are not valid across sessions
Adds a test to verify the fix

The error message now clearly explains:

ActorHandle objects are not valid across Ray sessions
When this typically happens (after shutdown/restart)
What the user should do (create a new actor handle)

Related issues

Fixes #59340

gemini-code-assist

Code Review

This pull request effectively addresses a crash that occurs when ray.kill() is used on an actor handle from a previous session. The fix is well-implemented across both the C++ and Python layers, preventing the crash and providing a clear, user-friendly error message. The addition of a dedicated test case ensures this scenario is covered going forward. I have one suggestion to improve the robustness of the error handling in the Python code.

python/ray/_private/worker.py

Signed-off-by: Seiji Eicher <[email protected]> Signed-off-by: kriyanshii <[email protected]>

Previously, calling ray.kill() on an ActorHandle from a previous Ray session (after ray.shutdown() and ray.init()) would crash the Python interpreter with a C++ assertion failure. This fix: 1. Prevents the crash by only calling OnActorKilled() in C++ when the kill operation succeeds 2. Catches the error in Python and converts it to a helpful ValueError explaining that ActorHandle objects are not valid across sessions 3. Adds a test to verify the fix The error message now clearly explains: - ActorHandle objects are not valid across Ray sessions - When this typically happens (after shutdown/restart) - What the user should do (create a new actor handle) Fixes the issue where the interpreter would crash instead of providing a useful error message. Signed-off-by: kriyanshii <[email protected]>

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Signed-off-by: Kriyanshi <[email protected]> Signed-off-by: kriyanshii <[email protected]>

…c threads (ray-project#55904) Signed-off-by: dayshah <[email protected]> Signed-off-by: kriyanshii <[email protected]>

…oject#59386) ## Description RLlib has nightly tests running currently however an exception was silently being ignored (`Object of type int64 is not JSON serializable`). This PR adds a numpy to json compatible function conversion for the results being serialized and remove the try / except to prevent an error occurring the future and not being alerted --------- Signed-off-by: Mark Towers <[email protected]> Co-authored-by: Mark Towers <[email protected]> Signed-off-by: kriyanshii <[email protected]>

…#59435) ## Description Some utility functions we moved do a recursive import of themselves. Instead, we need to import from the new location. Signed-off-by: kriyanshii <[email protected]>

…tResponse, and DeploymentResponseGenerator (ray-project#59363) Fixes ray-project#52654 ### Summary This PR improves the generic type annotations on Ray Serve's handle classes to enable better IDE support and type inference. It also adds a type checking test file to verify the annotations work correctly. ### Changes #### Type Annotation Improvements (`handle.py`) - **Generic return types**: Updated methods to return the generic type parameter `R` instead of `Any`: - `DeploymentResponse.result()` → `R` - `DeploymentResponse.__await__()` → `Generator[Any, None, R]` - `DeploymentResponseGenerator.__iter__()` → `Iterator[R]` - `DeploymentResponseGenerator.__next__()` → `R` - `DeploymentResponseGenerator.__aiter__()` → `AsyncIterator[R]` - `DeploymentResponseGenerator.__anext__()` → `R` - **mypy compatibility fixes**: - Added `cast()` for `Future` types in sync/async fetch methods to help mypy understand the conditional types - Aligned `_DeploymentHandleBase.options()` signature with `DeploymentHandle.options()` to fix override error - Refactored `remote()` to return directly from each branch instead of assigning different class types to a variable #### Type Checking Tests (`check_handle_typing.py`) Added a mypy test file that verifies: - Generic type `R` is preserved through `result()`, `__await__`, iteration methods - Generic type `T` is preserved through `options()` and method access - Placeholder tests for future mypy plugin (commented out) that will verify method return type inference ### How to Test ```bash mypy python/ray/serve/tests/typing_files/check_handle_typing.py python/ray/serve/handle.py \ --follow-imports=skip \ --ignore-missing-imports ``` ### Future Work A mypy plugin can be implemented to infer the return type of `.remote()` based on which deployment method is being called: ```python handle: DeploymentHandle[MyDeployment] response = handle.get_user.remote(123) # Plugin would infer DeploymentResponse[str] user = response.result() # Would be typed as str ``` The test file includes commented-out tests that should pass once the plugin is implemented. ## Tests From master ``` ❯ mypy python/ray/serve/tests/typing_files/check_handle_typing.py python/ray/serve/handle.py --follow-imports=skip --ignore-missing-imports python/ray/serve/handle.py:10: error: Module "ray._raylet" has no attribute "ObjectRefGenerator" [attr-defined] python/ray/serve/handle.py:162: error: Item "None" of "Optional[Any]" has no attribute "_run_router_in_separate_loop" [union-attr] python/ray/serve/handle.py:210: error: Item "None" of "Optional[Any]" has no attribute "assign_request" [union-attr] python/ray/serve/handle.py:229: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs [annotation-unchecked] python/ray/serve/handle.py:292: error: Unexpected keyword argument "timeout" for "result" of "Future" [call-arg] /home/ubuntu/.local/lib/python3.9/site-packages/mypy/typeshed/stdlib/_asyncio.pyi: note: "result" of "Future" defined here python/ray/serve/handle.py:319: error: Incompatible types in "await" (actual type "Union[concurrent.futures._base.Future[Any], _asyncio.Future[Any]]", expected type "Awaitable[Any]") [misc] python/ray/serve/handle.py:803: error: Incompatible types in assignment (expression has type "type[DeploymentResponse]", variable has type "type[DeploymentResponseGenerator]") [assignment] python/ray/serve/tests/typing_files/check_handle_typing.py:24: error: "DeploymentResponse" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:24: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:28: error: Expression is of type "Any", not "str" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:37: error: "DeploymentResponse" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:37: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:41: error: Expression is of type "Any", not "str" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:46: error: "DeploymentResponseGenerator" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:46: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:49: error: Expression is of type "Iterator[Any]", not "Iterator[int]" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:53: error: Expression is of type "Any", not "int" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:57: error: Expression is of type "Any", not "int" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:63: error: "DeploymentResponseGenerator" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:63: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:66: error: Expression is of type "AsyncIterator[Any]", not "AsyncIterator[int]" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:70: error: Expression is of type "Any", not "int" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:74: error: Expression is of type "Any", not "int" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:88: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:88: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:97: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:104: error: "DeploymentResponse" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:104: error: "DeploymentResponseGenerator" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:115: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:115: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:119: error: Expression is of type "Any", not "DeploymentHandle" [assert-type] python/ray/serve/tests/typing_files/check_handle_typing.py:119: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:151: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:151: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:177: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:177: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:200: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:200: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:230: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:230: note: Error code "type-arg" not covered by "type: ignore" comment python/ray/serve/tests/typing_files/check_handle_typing.py:262: error: "DeploymentHandle" expects no type arguments, but 1 given [type-arg] python/ray/serve/tests/typing_files/check_handle_typing.py:262: note: Error code "type-arg" not covered by "type: ignore" comment Found 30 errors in 2 files (checked 2 source files) ``` Because of changes in this PR ``` ❯ mypy python/ray/serve/tests/typing_files/check_handle_typing.py python/ray/serve/handle.py --follow-imports=skip --ignore-missing-imports python/ray/serve/handle.py:261: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs [annotation-unchecked] Success: no issues found in 2 source files ``` Signed-off-by: abrar <[email protected]> Signed-off-by: kriyanshii <[email protected]>

…y-project#59410) Signed-off-by: Kourosh Hakhamaneshi <[email protected]> Signed-off-by: kriyanshii <[email protected]>

fixes ray-project#59218 ### Performance Delta ```python from ray import serve from typing import List @serve.deployment(max_ongoing_requests=1000) class MyDeployment: @serve.batch(max_batch_size=10, batch_wait_timeout_s=1) async def handle_batch(self, requests: List[int]) -> List[int]: return [request + 1 for request in requests] async def __call__(self) -> List[int]: return await self.handle_batch(1) app = MyDeployment.bind() ``` `ray start --head --metrics-export-port=8080` -> `serve run batch_test:app` locust 100 users Metric | With Change | Master | Δ (Master – With Change) -- | -- | -- | -- Requests | 32,033 | 33,541 | +1,508 Fails | 0 | 0 | 0 Median (ms) | 170 | 170 | 0 95%ile (ms) | 240 | 240 | 0 99%ile (ms) | 280 | 270 | –10 ms Average (ms) | 172.98 | 171.87 | –1.11 ms Min (ms) | 70 | 84 | +14 ms Max (ms) | 352 | 365 | +13 ms Average size (bytes) | 1 | 1 | 0 Current RPS | 581.9 | 604.1 | +22.2 Current Failures/s | 0 | 0 | 0 --------- Signed-off-by: abrar <[email protected]> Signed-off-by: kriyanshii <[email protected]>

…#59396) updating default python version to py3.10 --------- Signed-off-by: elliot-barn <[email protected]> Signed-off-by: kriyanshii <[email protected]>

@amogkam

…ter_batches (ray-project#58467) ## Description This PR will: - Batch block resolution in `resolve_block_refs()` so `iter_batches()` issues one `ray.get()` per chunk of block refs instead of per ref. The chunk size is configurable using new `DataContext.iter_get_block_batch_size` knob. - Added a test that proves that `resolve_block_refs()` actually batches the `ray.get()` calls. ## Related issues Raised by @amogkam in `python/ray/data/_internal/block_batching/util.py` ## Additional information Simple benchmark available: https://gist.github.com/YoussefEssDS/40de959a42a19334b8dac8bd217c319b --------- Signed-off-by: YoussefEssDS <[email protected]> Signed-off-by: kriyanshii <[email protected]>

…ct#59402) ## Description - Streamlining `Unique` aggregation to avoid back and forth conversion, instead rebasing it onto `BlockColumnAccessor.unique` - Cleaned up corresponding `Preprocessor`s (like `OrdinalEncoder`) ## Related issues > Link related issues: "Fixes ray-project#1234", "Closes ray-project#1234", or "Related to ray-project#1234". ## Additional information > Optional: Add implementation details, API changes, usage examples, screenshots, etc. --------- Signed-off-by: Alexey Kudinkin <[email protected]> Signed-off-by: kriyanshii <[email protected]>

## Description Abstracting the delta calculation in autoscaling so we can implement custom logic on it. ## Related issues ## Additional information --------- Signed-off-by: You-Cheng Lin <[email protected]> Signed-off-by: kriyanshii <[email protected]>

… replicas (ray-project#59373) Signed-off-by: Kourosh Hakhamaneshi <[email protected]> Signed-off-by: kriyanshii <[email protected]>

no update in the past 2.5 years, all wheels link in yaml file already stopped working. also `pip install -U` is frowned upon. Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

… grpc calls (ray-project#59431) ## Description Adds token authentication to OpenTelemetry metric exports. The open telemetry grpc client is created internally within the Opentelemetry sdk and hence does not add the common interceptor automatically hence requiring us to manually include and pass the token header. fixes ray-project#59361 --------- Signed-off-by: sampan <[email protected]> Co-authored-by: sampan <[email protected]> Signed-off-by: kriyanshii <[email protected]>

so that it does not include other file changes that are committed to master branch. the script will be deprecated with the next `rayci` upgrade, but just correcting this for the record and save a little bit of costs before the upgrade. Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

those default are not really being used any more, but put some sane value for them anyways Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

not used anywhere any more. Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

unifies docs dependency set to python 3.9 all docs builds should get unified to run on python 3.10 Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

removing 3.9 image builds --------- Signed-off-by: elliot-barn <[email protected]> Signed-off-by: kriyanshii <[email protected]>

… using stale snapshot (ray-project#59454) ## Description 1. Start a new Ray cluster with two nodes with FT 2. Kill GCS and then restart 3. Fetch the cluster status from the autoscaler and check it still knows the two nodes The flaky issue is because the `status` gotten from `get_cluster_status(cluster.address)` is static. The autoscaler might still be working and getting correct info from the restarted GCS, but `wait_for_condition` was previously checking a static value. This PR fixes this by making `wait_for_condition` properly check by getting a fresh `cluster_status` on every check. I noticed this because it reproduces consistently in my local dev environment. ## Test ```shell (venv) (base) ubuntu@devbox:~/ray$ for i in {1..4}; do echo "=== Run $i ===" && python -m pytest python/ray/tests/test_gcs_fault_tolerance.py::test_autoscaler_init -v --tb=short 2>&1 | tail -5; done === Run 1 === collecting ... collected 1 item python/ray/tests/test_gcs_fault_tolerance.py::test_autoscaler_init[ray_start_cluster_head_with_external_redis0] PASSED [100%] ============================== 1 passed in 15.01s ============================== === Run 2 === collecting ... collected 1 item python/ray/tests/test_gcs_fault_tolerance.py::test_autoscaler_init[ray_start_cluster_head_with_external_redis0] PASSED [100%] ============================== 1 passed in 16.55s ============================== === Run 3 === collecting ... collected 1 item python/ray/tests/test_gcs_fault_tolerance.py::test_autoscaler_init[ray_start_cluster_head_with_external_redis0] PASSED [100%] ============================== 1 passed in 17.49s ============================== === Run 4 === collecting ... collected 1 item python/ray/tests/test_gcs_fault_tolerance.py::test_autoscaler_init[ray_start_cluster_head_with_external_redis0] PASSED [100%] ============================== 1 passed in 15.57s ============================== ``` --------- Signed-off-by: yicheng <[email protected]> Co-authored-by: yicheng <[email protected]> Signed-off-by: kriyanshii <[email protected]>

…-project#59417) Shows users how to use `download` to download from URI tables. --------- Signed-off-by: Richard Liaw <[email protected]> Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Signed-off-by: kriyanshii <[email protected]>

…ray-project#59458) Reverts ray-project#59387 Signed-off-by: kriyanshii <[email protected]>

@DeveloperAPI

Add API stability annotation for ActorHandleNotFoundError Annotate ray.exceptions.ActorHandleNotFoundError with @DeveloperAPI Fixes ci/lint/check_api_annotations.py failure reporting missing API stability annotation

python/ray/tests/test_ray_shutdown.py

python/ray/_private/worker.py

updated tests in test_ray_shutdown.py removed unnecessary comments from ray/_private/worker.py

codope

@kriyanshii Overall looks good. Can you please fix the premerge ci failures?

kriyanshii · 2026-01-06T10:09:29Z

working on it.

kriyanshii · 2026-01-06T11:57:20Z

@codope done! ✅

edoakes

LGTM thanks for the contribution @kriyanshii

There was a test failure on premerge CI, but it looks unrelated. I will re-run the CI.

kriyanshii · 2026-01-08T09:28:18Z

all checks have passed with recent merge.

…-project#59425) Fixes the issue where the interpreter would crash instead of providing a useful error message. Previously, calling ray.kill() on an ActorHandle from a previous Ray session (after ray.shutdown() and ray.init()) would crash the Python interpreter with a C++ assertion failure. This fix: 1. Prevents the crash by only calling OnActorKilled() in C++ when the kill operation succeeds 2. Catches the error in Python and converts it to a helpful ValueError explaining that ActorHandle objects are not valid across sessions 3. Adds a test to verify the fix The error message now clearly explains: - ActorHandle objects are not valid across Ray sessions - When this typically happens (after shutdown/restart) - What the user should do (create a new actor handle) Fixes ray-project#59340 --------- Signed-off-by: kriyanshii <[email protected]> Co-authored-by: Edward Oakes <[email protected]> Signed-off-by: jasonwrwang <[email protected]>

kriyanshii requested a review from a team as a code owner December 14, 2025 10:00

gemini-code-assist bot reviewed Dec 14, 2025

View reviewed changes

python/ray/_private/worker.py Outdated Show resolved Hide resolved

ray-gardener bot added core Issues that should be addressed in Ray Core community-contribution Contributed by the community labels Dec 14, 2025

edoakes reviewed Dec 15, 2025

View reviewed changes

python/ray/_private/worker.py Outdated Show resolved Hide resolved

eicherseiji and others added 25 commits December 16, 2025 16:36

[serve][llm] Fix LLM target_ongoing_requests default (ray-project#59323)

752697e

Signed-off-by: Seiji Eicher <[email protected]> Signed-off-by: kriyanshii <[email protected]>

Update python/ray/_private/worker.py

65ba9ec

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Signed-off-by: Kriyanshi <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[core] Move CreateCall to polling thread and add documentation on grp…

954810b

…c threads (ray-project#55904) Signed-off-by: dayshah <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[RLlib] Fix recursive imports in old test utils location (ray-project…

d0851de

…#59435) ## Description Some utility functions we moved do a recursive import of themselves. Instead, we need to import from the new location. Signed-off-by: kriyanshii <[email protected]>

[Serve] Fix make_fastapi_class_based_view for inherited methods (ra…

86ac775

…y-project#59410) Signed-off-by: Kourosh Hakhamaneshi <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[release] Change release test default python version 310 (ray-project…

df332d4

…#59396) updating default python version to py3.10 --------- Signed-off-by: elliot-barn <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[Serve][LLM] Add dispatch API for control plane operations across all…

076108f

… replicas (ray-project#59373) Signed-off-by: Kourosh Hakhamaneshi <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[scripts] remove install-nightly (ray-project#59441)

9fade94

no update in the past 2.5 years, all wheels link in yaml file already stopped working. also `pip install -U` is frowned upon. Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[release test] add helper that lists tests (ray-project#59253)

3230309

Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[ci] change base defaults to python 3.10 (ray-project#59442)

aeeeff6

those default are not really being used any more, but put some sane value for them anyways Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[ci] remove residue of python 3.9 ci bases (ray-project#59443)

69893e9

not used anywhere any more. Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[doc] removes docs depsets except python 3.10 (ray-project#59450)

69c5402

unifies docs dependency set to python 3.9 all docs builds should get unified to run on python 3.10 Signed-off-by: Lonnie Liu <[email protected]> Signed-off-by: kriyanshii <[email protected]>

[ci][release] removing 3.9 builds (ray-project#59447)

97834b8

removing 3.9 image builds --------- Signed-off-by: elliot-barn <[email protected]> Signed-off-by: kriyanshii <[email protected]>

Revert "[Data] Fix DataContext deserialization issue with StatsActor" (…

dd50c82

…ray-project#59458) Reverts ray-project#59387 Signed-off-by: kriyanshii <[email protected]>

kriyanshii and others added 2 commits December 18, 2025 22:08

Signed-off-by: kriyanshii <[email protected]>

1472a8c

Add API stability annotation for ActorHandleNotFoundError Annotate ray.exceptions.ActorHandleNotFoundError with @DeveloperAPI Fixes ci/lint/check_api_annotations.py failure reporting missing API stability annotation

Merge branch 'master' into master

31ae72c

codope reviewed Dec 19, 2025

View reviewed changes

python/ray/tests/test_ray_shutdown.py Outdated Show resolved Hide resolved

python/ray/_private/worker.py Outdated Show resolved Hide resolved

codope mentioned this pull request Dec 19, 2025

[core] Fix ray.kill crash when actor handle is from different session #59542

Closed

kriyanshii and others added 7 commits December 19, 2025 19:28

Signed-off-by: kriyanshii <[email protected]>

b32ce33

updated tests in test_ray_shutdown.py removed unnecessary comments from ray/_private/worker.py

Merge branch 'master' into master

64d4c23

Merge branch 'ray-project:master' into master

d2e03b4

Merge branch 'master' into master

66e2932

Merge branch 'ray-project:master' into master

b8b9a65

Merge branch 'ray-project:master' into master

a40d599

Merge branch 'ray-project:master' into master

a584b0f

kriyanshii requested a review from codope January 3, 2026 17:19

kriyanshii added 3 commits January 4, 2026 09:48

Merge branch 'ray-project:master' into master

c6702bb

Merge branch 'ray-project:master' into master

d9a658c

Merge branch 'ray-project:master' into master

464b550

codope reviewed Jan 6, 2026

View reviewed changes

Merge branch 'master' into master

a982498

kriyanshii requested a review from codope January 6, 2026 16:09

kriyanshii added 2 commits January 7, 2026 08:30

Merge branch 'master' into master

aad0a4f

Merge branch 'master' into master

607985a

edoakes approved these changes Jan 7, 2026

View reviewed changes

Merge branch 'master' into master

7872637

edoakes enabled auto-merge (squash) January 7, 2026 15:32

Merge branch 'master' into master

4f3c083

github-actions bot disabled auto-merge January 8, 2026 05:18

edoakes merged commit 39aa361 into ray-project:master Jan 8, 2026
6 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[core] Fix crash when killing actor handle from previous session #59425

[core] Fix crash when killing actor handle from previous session #59425

kriyanshii commented Dec 14, 2025

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codope left a comment

Uh oh!

kriyanshii commented Jan 6, 2026

Uh oh!

kriyanshii commented Jan 6, 2026

Uh oh!

edoakes left a comment

Uh oh!

kriyanshii commented Jan 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

18 participants

[core] Fix crash when killing actor handle from previous session #59425

[core] Fix crash when killing actor handle from previous session #59425

Conversation

kriyanshii commented Dec 14, 2025

Description

Related issues

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codope left a comment

Choose a reason for hiding this comment

Uh oh!

kriyanshii commented Jan 6, 2026

Uh oh!

kriyanshii commented Jan 6, 2026

Uh oh!

edoakes left a comment

Choose a reason for hiding this comment

Uh oh!

kriyanshii commented Jan 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

18 participants