Stop ractor workers after receiving their exceptions - #378
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Send the normal stop message to a Ractor after consuming its exception result, on both receive paths.
Reproduction and verification
When a callback raises, the Ractor sends its exception result and loops back to receive. The parent currently removes or skips it without sending a stop message. Three bounded fixtures covering initial/final and mid-stream failures each leave one waiting worker on baseline; the candidate leaves none. The fixture explicitly releases baseline workers afterward.
Three lifecycle fixtures pass; 29 existing Ractor examples pass with seven existing pending cases. The original callback error is still raised.
The combined installed-release candidate passes 800 model checks across direct, thread, process and Ractor modes. Existing selected suite: 165 examples, zero failures, nine pending, baseline and candidate on rbenv Ruby 4.0.6. Global process-name kill tests and the 200-process stress example were excluded for shared-host safety. SQLite examples use temporary databases. An external verification bundle uses already-installed dependencies; upstream Gemfile/lockfile/tests remain unchanged.
Runtime RuboCop passes. Full upstream RuboCop reports the same pre-existing RSpec/MatchWithSimpleRegex offense in spec/parallel_spec.rb:278 on both versions; no full green-lint claim. Gem packaging retains 2.1.0, Ruby >= 3.3, all four published paths and metadata, with no dependency changes.
Compatibility and limitations
Successful work and error propagation are unchanged. This fixes ordinary callback-error/Break result cleanup, not arbitrary start/finish/producer exceptions or forced cancellation. Ruby 4.0.6 exercised; the Ruby 3 Ractor.yield branch awaits upstream CI.
No tests were added or modified under the consuming repository's no-new-tests policy. Reproductions/model checks are external scratch scripts. No production operations or claim of complete concurrency/platform coverage.