-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
💥 Changes to responses handling, motivated by thread-safety #93
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds reasonable.
However, I think old-style responses should be supported until the release of Ruby 3.3.
Agreed. IMO, our deprecation policy for anything non-trivial should be to |
It sounds fine! |
There is no one single client_thread, this isn't used internally, and it's misleading to external users. However, adding `#reciever_thread` (or `#receiver_fiber`) might be useful.
89ae479
to
223055e
Compare
Calling `#responses` with no block is deprecated, as it can't be made thread-safe and backward-compatible. However, the deprecation warning is commented out for now, until after I can check the test suites for the rails and mail gems and submit PRs there if necessary. For convenience, an optional `type` paramater has been added to `#responses`, to yield only the array for that type of response. Added `#clear_responses` as a convenience method for the common "read and delete" pattern, and to provide a thread-safe responses method that doesn't require a block. The response handlers methods are now synchronized, but `#response_handlers` now returns a frozen clone to alert users who had manipulated it directly. Hopefully very few are affected, but this change is backwards incompatible. N.b: there currently is no API for inserting a response_handler into a particular position in the array. Also, improve the yields_in_test_server_thread test helper: it no longer reads `last_tag` from the block result, it sets a short `IO#timeout` in ruby 3.2+, it uses a slightly longer timeout for overall test completion, and it defines `sock.getcmd` so the tests can read more intuitively than using a proc passed into the block.
223055e
to
800edb8
Compare
@shugo For what it's worth, I've commented out the |
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. This allows us to prepare dependent projects for the new behavior before their logs are flooded with deprecation warnings.
This was extracted from #93 and split into a separate PR. A new config option is added: `responses_without_block`. This is provided as a workaround, until dependant projects can update their usage. A future release may remove this backwards compatibility, but _no sooner_ than v0.6.
This was extracted from #93 and split into a separate PR. A new config option is added: `responses_without_block`. This is provided as a workaround, until dependant projects can update their usage. A future release may remove this backwards compatibility, but _no sooner_ than v0.6.
This was extracted from #93 and split into a separate PR. A new config option is added: `responses_without_block`. This is provided as a workaround, until dependant projects can update their usage. A future release may remove this backwards compatibility, but _no sooner_ than v0.6.
This was extracted from #93 and split into a separate PR. A new config option is added: `responses_without_block`. This is provided as a workaround, until dependant projects can update their usage. A future release may remove this backwards compatibility, but _no sooner_ than v0.6.
Calling
#responses
with no arguments or block is deprecated, as itcan't be made thread-safe and backward-compatible. For convenience, an
optional
type
paramater has been added to#responses
, to yield onlythe array for that type of response.
Added
#clear_responses
as a convenience method for the common "readand delete" pattern, and to provide a thread-safe responses
method that doesn't require a block.
The response handlers methods are synchronized, but
#response_handlers
now returns a frozen clone to alert users who had manipulated it
directly. Hopefully very few are affected, but this change is backwards
incompatible. N.b: there currently is no API for inserting a
response handler into a particular position in the array.
Also, improve yields_in_test_server_thread test helper: it no longer
reads
last_tag
from the block result, it sets a shortIO#timeout
inruby 3.2+, it uses a slightly longer timeout for overall test
completion, and it defines
sock.getcmd
so the tests can