The concurrent-ruby gem is a toolset containing many concurrency
utilities. Many of these utilities include runtime-specific
optimizations when possible. Rather than clutter the Rails codebase with
concurrency utilities separate from the core task, such tools can be
superseded by similar tools in the more specialized gem. This commit
replaces `ActiveSupport::Concurrency::Latch` with
`Concurrent::CountDownLatch`, which is functionally equivalent.
we were already generating a path in the previous code (it was just not
returned), so lets just use the already computed path to popluate the
PATH_INFO header
We should roundtrip the parameters through their respective encoders /
decoders so that the controller will get parameters similar to what they
actually get in a real world situation
We should convert request parameters to a query string, then let the
request object parse that query string. This should give us results
that are more similar to the real-world
Instead of trying to manually clear out a request object, lets just
allocate a new one. The rack ENV is reused and cleaned (still), but the
request object is not.
Variants are typically set in the controller based on some attribute of
the request that the browser sent. We should make our tests more in
line with reality by doing the same and not mutating the request object.
This change decouples `cookie_jar` allocation from the request object.
We need this for moving controller tests to integration tests so we can
access the `cookie_jar` object separately.
This sort of documentation style comes from 2009, probably due to
the merging of merb (see 38b608ecab (diff-017d9bc9b1d2bdae199b938d72c15488R120)).
Rails follows Ruby's convention to define which values are "truthy" or
"falsey", so there is no need to specify that the returned value must
strictly be a TrueClass or FalseClass. /cc @fxn
Clarify the `url_for` usage in mailers.
Re-add the documentation about `url_for` and Route's path parameters,
first introduced by 5c4f1859970d06228a0b67cad6d4486c1526ef2a.
This was reported on #15097 and until it is decided to deprecate it
or not, I believe the documentation should exist.
Using `assert_predicate` and `assert_match` instead of just `assert` is
preferrable because better error messages are output.
In the case of `assert response.cookies.empty?` the error message was
`Failed assertion, no message given.` but now with `assert_predicate` it
will be `Expected {"user_name"=>"david"} to be empty?.`
For `assert_match(/user_name=david/,
response.headers["Set-Cookie"])` as well, the message returned was
unhelpful - `Failed assertion, no message given.` but now will tell what
was expected and what was returned with `Expected /user_name=david/ to
match "user_name=nope; path=/".`
Add the possibility to only filter parameters based on
their full path instead of relying on the immediate key.
config.filter_parameters += ['credit_card.code']
{ 'credit_card' => { 'code' => '[FILTERED]' },
'source' => { 'code' => '<%= puts 5 %>' } }
