Putting ".localhost" at the end causes 4 IPAddr::InvalidAddressError
exceptions to be raised and rescued during every request when the
HostAuthorization middleware attempts to compare an IPAddr with a
"localhost" string.
This PR adds `image/webp` to the default array of variable content
types. Without this commit if we want to "handle" webp images
overwriting `config.active_storage.variable_content_types` was
necessary.
Follow up #38613 and #38094
Action View and Action Pack unit tests run in parallel by default
and the number of parallel workers is defined by `PARALLEL_WORKERS` value.
To investigate some random failures with SEED,
Disabling Parallel testing sometimes helps to isolate these failures.
- ### Problem
If we use `perform_enqueued_jobs` without a block, a job that
uses a retry mechanism to reeenqueue itself would get performed
right away.
This behaviour make sense when using `perform_enqueued_jobs` with
a block.
However I'm expecting `perform_enqueued_jobs` without a block to
perform jobs that are **already** in the queue not the ones that
will get enqueued afterwards.
### Solution
Dup the array of jobs given to avoid future mutation.
- ### Problem
If we use `perform_enqueued_jobs` without a block,
a job that raises an error wouldn't be appended to
the list of `performed_jobs`.
### Solution
Push the job in the array before it is actually performed.
Make it clearer how the key and value are derived in both cases, and use
the same sentence structure so that it's easier understand one method in
terms of the other.
Also add an example of passing a default value to `index_with`.
This method was jumping through extra hoops to find the name of the
class the connection is stored on when we can get it from the connection
itself. Since we already have the connection we don't need to loop through the
pools.
In addition, this was using the wrong class name. The class name for the
schema migration should come from the connection owner class, not from
the `db_config.name`. In this case, `db_config.name` is the name of the
configuration in the database.yml. Rails uses the class name to lookup
connections, not the db config name, so we should be consistent here.
While working on this I noticed that we were generating an extra schema
migration class for `ActiveRecord::Base`. Since `ActiveRecord::Base` can
and should use the default and we don't want to create a new one for
single db applications, we should skip creating this if the spec name is
`ActiveRecord::Base`. I added an additional test that ensures the class
generation is correct.
We don't actually need this since the only reason it exists is to pass
the owning class name down to the `handler`. This removes a level of
indirection and an unnecessary accessor on db_config. db_config
shouldn't have to know what class owns it, so we can just remove this
and pass it to the handler.
The Symbol case is needed to preserve current behavior. This doesn't
need a changelog because it's changing un-released behavior.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
This line was creating a new hash config, but we should always have a
hash config to lookup at this point.
Previously we needed this code because the pool name was merged into the
hash. Now it's an accessor on the db_config, so we have no reason to
create a new hash config.
Also, change env_name to name since it's only an env in a single db
application or an application with no arguments for
establish_connection.
`config_or_env` can only be `nil` if called by `establish_connection`.
If `connects_to` had a `connects_to database: { writing: nil }` that
would make no sense.
This is a really minor refactoring that moves the assignment if `nil`
into the only method that can actually receive nil. Then
`resolve_config_for_connection` will never get nil passed to it.
If I had had these tests previously I would have not created PR #38658
and then promptly realize I needed to revert it.
We need to load and parse the configurations twice. Once before the
environment is loaded to create the named tasks and once after the
environment is loaded to have the real configurations. The configs
loaded before the env have the ERB stripped out and aren't valid
configs.
RailsInstaller is no longer maintained and its latest supported Ruby
version is 2.3 which Rails no longer supports.
In contrast, RubyInstaller supports Ruby 2.7, 2.6, 2.5, 2.4, 2.3, and 2.2 which
are the only Ruby versions necessary for Rails 6.x and 5.x at this point.
Fixes#38654
[ci skip]
This reverts commit 9a5bc246d7, reversing
changes made to 227ff44e36.
I realized afterwards that this was written this way for a reason and it
wasn't accidental. The databases loaded in `for_each` are not complete
database configs because these are generated from the database yaml
before the Rails env is loaded. So we actually do need to refetch the
correct database configuration objects after we've loaded the Rails env.
This adds a StringInquirer subclass EnvironmentInquirer that
predefines the three default environments as query methods, in
order to avoid dispatching through `method_missing` for every call
to those methods. The original StringInquirer was not modified due
to the side effects of having new env-related methods on it. This
new class was not implemented using lazy method definition to
avoid the open-ended possibility of defining a new method for all
query calls. The three default environments should cover a high
percentage of real-world uses, and users with custom environments
could add their own to this class.
Fixes#37803.
While working on something else I noticed this code was duplicated. It
was returning `name` from `for_each` and then we'd have to lookup the
`db_config` again from the `name` and `env`. We can instead just return
`db_config` from `for_each` and clean up these tasks a little bit.
author Aditya Narsapurkar <adityanarsapurkar@yahoo.com> 1582316102 +0530
committer Aditya Narsapurkar <adityanarsapurkar@yahoo.com> 1583159505 +0530
parent 6d0895a489
author Aditya Narsapurkar <adityanarsapurkar@yahoo.com> 1582316102 +0530
committer Aditya Narsapurkar <adityanarsapurkar@yahoo.com> 1583159327 +0530
Randomize jitter
- This PR attempts to fix a problem with ActiveJob jitter where the `determine_jitter_for_delay` value may not always be randomized. Especially when the jitter delay multplier is between 1 and 2 it always returns 0.
- With this change, we pass a range to `Kernel.rand` beginning with 0 to the `jitter_multiplier`. With positive float values, the return value will be a random float number from the range.
- Includes test cases to verify random wait time when the jitter_multiplier is between 1 and 2.
- Updated relevant test cases stubbing the `Kernel.rand` method, refactored some by removing unwanted stubs for `Kernel.rand` method where jitter is falsey.
Fixed rubocop issue - used assert_not_equal instead of refute_equal in test case
Fixed rubocop issue - used assert_not_equal instead of refute_equal in test case
Fixed rubocop issue - used assert_not_equal instead of refute_equal in test case
Review updates - separated test cases for random wait time with default and exponentially retrying jobs
- Another test case added to make sure negative wait time does not affect the randomization
Review updates
- Instead of using Kernel.rand with range, used simple multiplication with Kernel.rand for calculating delay for jitter
- Updates to the tests according to changes
This is done because concerns of respective steps can be separated,
which in turns leads to easier walkthrough and verbosity. Also
stretching a function to large horizontal bounds doesn't looks good.
Rafael França