`ostruct` was being implictly required by the `json` gem. But once it
was upgraded, these tests failed to initialize `OpenStruct`.
While we're trying to remove `ostruct` usage in #51510, CI is currently
failing so I'm pushing these in the mean time.
If running in an interactive console, the user will be given the option to correct the error and re-run the tests.
Co-authored-by: Gannon McGibbon <gannon.mcgibbon@gmail.com>
For example, if you run `rails test test/models/usr_tsst.rb` and the file does not exist,
Rails will suggest `test/models/users_test.rb` as a possible file.
```
Could not load test file: test/models/usr_tsst.rb. Did you mean? test/models/user_test.rb
```
Co-authored-by: Aaron Patterson <aaron@rubyonrails.org>
Replaced by `#lease_connection` to better reflect what it does.
`ActiveRecord::Base#connection` is deprecated in the same way
but without a removal timeline nor a deprecation warning.
Inside the Active Record test suite, we do remove `Base.connection`
to ensure it's not used internally.
Some callsites have been converted to use `with_connection`,
some other have been more simply migrated to `lease_connection`
and will serve as a list of callsites to convert for
https://github.com/rails/rails/pull/50793
Extracted from: https://github.com/rails/rails/pull/50793
Similar to the recent refactoring of schema caches, rather than to directly
hold a connection, they now hold a pool and checkout a connection when needed.
https://buildkite.com/rails/rails-nightly/builds/191#018dc3d1-902c-4b01-a82c-b662ebdbe567/1182-1188
Increasing timeout value from 10 to 100 for assert_output method addresses these failures.
- Ruby built with debug options that takes more than 20 seconds and gets failed
Here, the Ruby is built with these options:
```
cppflags="-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1" optflags="-O3 -fno-inline"
```
```ruby
$ ruby -v
ruby 3.4.0dev (2024-02-20T11:52:09Z master c22cb960cf) [x86_64-linux]
$ time bin/test test/application/dbconsole_test.rb
Run options: --seed 5685
F
Failure:
ApplicationTests::DBConsoleTest#test_use_value_defined_in_environment_file_in_database_yml [test/console_helpers.rb:19]:
"sqlite>" expected, but got:
.
Expected "" to include "sqlite>".
bin/test test/application/dbconsole_test.rb:21
F
Failure:
ApplicationTests::DBConsoleTest#test_respect_environment_option [test/console_helpers.rb:19]:
"sqlite>" expected, but got:
.
Expected "" to include "sqlite>".
bin/test test/application/dbconsole_test.rb:43
Finished in 10.105668s, 0.1979 runs/s, 0.3958 assertions/s.
2 runs, 4 assertions, 2 failures, 0 errors, 0 skips
real 0m21.031s
user 0m8.665s
sys 0m2.286s
$
```
- Ruby built without debug options that finishes within second.
```ruby
$ ruby -v
ruby 3.4.0dev (2024-02-20T11:52:09Z master c22cb960cf) [x86_64-linux]
$ time bin/test test/application/dbconsole_test.rb
Run options: --seed 1479
..
Finished in 5.463076s, 0.3661 runs/s, 1.0983 assertions/s.
2 runs, 6 assertions, 0 failures, 0 errors, 0 skips
real 0m9.942s
user 0m2.288s
sys 0m2.173s
$
```
This commit address Rails Nightly failure at
https://buildkite.com/rails/rails-nightly/builds/191#018dc3d1-8fb2-4c35-ad1d-bd3891757361/1310-1318
This issue reproduces when the `default-mysql-client` apt package installs `mysql-client-8.0`
that raises `CR_CONN_HOST_ERROR` which is mapped to `ActiveRecord::DatabaseConnectionError`
while `mariadb-client` raises `CR_CONNECTION_ERROR` error which is mapped to `ActiveRecord::ConnectionNotEstablished`.
In this test, whichever exception `ActiveRecord::ConnectionNotEstablished` or `DatabaseConnectionError` is fine
as long as the connection is invalid.
- Steps to reproduce
Run this step at Linux box on Ubuntu Jammy or whatever `default-mysql-client` installs MySQL client, not MariaDB one.
```
git clone https://github.com/rails/rails
cd rails/railties
bundle install
bin/test test/application/initializers/frameworks_test.rb:285
```
- Failure fixed by this commit
```ruby
$ bin/test test/application/initializers/frameworks_test.rb:285
Run options: --seed 32832
F
Failure:
ApplicationTests::FrameworksTest#test_expire_schema_cache_dump_if_the_version_can't_be_checked_because_the_database_is_unhealthy [test/application/initializers/frameworks_test.rb:285]:
Expected /Failed to validate the schema cache because of ActiveRecord::ConnectionNotEstablished/ to match "Failed to validate the schema cache because of ActiveRecord::DatabaseConnectionError: There is an issue connecting with your hostname: 127.0.0.1.\n\nPlease check your database configuration and ensure there is a valid connection to your database.\n".
bin/test test/application/initializers/frameworks_test.rb:263
Finished in 6.299418s, 0.1587 runs/s, 0.6350 assertions/s.
1 runs, 4 assertions, 1 failures, 0 errors, 0 skips
```
- `default-mysql-client` package used by Rails CI
3158d00b48/Dockerfile (L91)
`default-mysql-client` installs different package per distribution, Ja
https://packages.ubuntu.com/jammy/default-mysql-clienthttps://packages.debian.org/bookworm/default-mysql-client
- Each error message are defined in these lines by these commits:
-- MariaDB
eeba940311/sql-common/errmsg.c (L32)9075973dbf
-- MySQL
824e2b4064/libmysql/errmsg.cc (L39)964d5fdb02
Another refactoring in relation to https://github.com/rails/rails/pull/50793
But it makes sense even without it.
Rather than each connection to have its own `BoundSchemaReflection`,
we can instead have `BoundSchemaReflection` hold a `ConnectionPool`,
from which it can checkout a connection to perform queries when needed.
If the current thread already leased a connection, it will be used.
This simplifies the interface quite a bit.
This will be eager loaded by the define_attribute_methods initializer
now that the schema cache can be automatically loaded for all
connection if the file is present on disk after #48716.
- If an application has files named `*_test.rb` in the
"fixtures/files" folder, they were picked up to be loaded.
In most cases this would result in a LoadError as its likely
those files include code that can't be loaded.
Configure ActiveRecord::Encryption (ARE) on ActiveRecord::Base (AR)
loading, so that ARE configs are ready before AR models start using
`encrypts` to declare encrypted attributes.
This means that you can add ARE configurations in initializers, as long
as you don't trigger the loading of ActiveRecord::Base or your AR models
in prior initializers.
Ref: https://github.com/rails/rails/pull/50793
Transactional fixtures are currently tightly coupled with the pool
active connection. It assumes calling `pool.connection` will memoize
the checked out connection and leverage that to start a transaction
on it and ensure all subsequent accesses will get the same connection.
To allow to remove checkout caching (or make it optional), we first
must decouple transactional fixtures to not rely on it.
The idea is to behave similarly, but store the connection in
the pool as a special "pinned" connection, and not as the regular
active connection.
This allows to always return the same pinned connection,
but without necessarily assigning it as the active connection.
Additionally, this pinning impact all threads and fibers, so
that all threads have a consistent view of the database state.
When set, an `ActiveRecord::InvalidMigrationTimestampError` will be raised if the timestamp
prefix for a migration is more than a day ahead of the timestamp associated with the current time.
This is done to prevent forward-dating of migration files, which can impact migration generation
and other migration commands.
It is turned off by default, but will be turned on for applications starting in Rails 7.2.
When the application has more than one database configuration, only
the primary was being loaded by default on boot time. All the other
connection pools were loading the schema cache lazily.
This logic can be found in:
351a8d9bc9/activerecord/lib/active_record/connection_adapters/pool_config.rb (L13)351a8d9bc9/activerecord/lib/active_record/railtie.rb (L149-L178)
The lazy code path wasn't using the same logic to determine the name
of the default schema cache file that the Railties uses, so it
was loading the schema cache of the primary config to all the other
configs. If no table name coincided nothing bad would happen, but if
table names coincided, the schema would be completly wrong in all
non-primary connections.
Following the discussion in #50770, the new format will be:
`[dasherized-app-name]([colorized-env])>`
For example, if the app's module name is `MyApp`, the prompt will be:
`my-app(dev)>`, where the `dev` part will be colored.
Update railties/lib/rails/commands/console/console_command.rb
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
Update changelog
Setting `TERM=dumb` is enough to disable colorization in those tests.
Mocked app should also load console helpers
Move console method extension to IRBConsole's constructor
Test IRB autocompletion control without mutating ENV
Control IRB autocompletion without mutating ENV
Correct local variable name
This hook was only running when routes were reloaded, but not on boot.
The goal was to run any time routes are loaded. This commit fixes it
and adds a test.
Fixes#50720.
Previously, the Rails application would reload due to changes
in some files outside the autoload paths.
For instance, editing `app/README.md` would trigger a reload,
even though the reloaded classes and modules were identical
to those loaded previously.
This commit fixes this issue by ensuring the application reloads correctly
according to `Rails.autoloaders.main.dirs`, thereby preventing unnecessary reloads.
https://github.com/rails/rails/issues/37011#issuecomment-1322560651
Follow-up to #50050.
Using `args.none?` does not catch the case when all args are `false` or
`nil`. Therefore, this commit changes the condition to `args.empty?`.
This commit also changes the error message to more closely match Ruby's
error messages when trying to pass an arg to a getter method:
```ruby
Rails.configuration.x(false)
# => wrong number of arguments (given 1, expected 0) (ArgumentError)
Rails.configuration.x.i_do_not_exist(false)
# => wrong number of arguments (given 1, expected 0) when reading configuration `i_do_not_exist` (ArgumentError)
```
The flexibility provided by `config.x` supports arbitrarily defining new
configuration objects on-the-fly. Each new intermediate configuration
object is constructed during chaining from its ancestor through a method
invocation made without arguments.
Conversely, writing to leaf configuration values occurs when the invoked
method's name ends with `=`, and the new configuration value is assigned
to whatever that method's arguments are.
There are no cases when reading from a `config.x` value or building the
intermediate values involves arguments.
Prior to this commit, a read invoked with a method arguments would
ignore those arguments. While this is robust and error-free, it's
possible to obscure misuse.
For example, consider a line like:
```ruby
config.x.my_config.enabled = true
config.x.my_config.enabled #=> true
```
Now consider that first line with a typo that omits the `=`:
```ruby
config.x.my_config.enabled true
config.x.my_config.enabled #=> nil
```
This commit aims to provide more direct feedback for scenarios like the
one above. There aren't legitimate use cases for invoking `#enabled`
with arguments, so raise a `ArgumentError` when encountering a read with
arguments.
* Apply autocorrection by RuboCop to files generated by `bin/rails generate`
## Motivation / Background
RuboCop has now been included by default (#50456).
By adding the following tip to the default configuration, user can apply RuboCop's autocorrection to
code generated by `bin/rails generate` (e.g., migration file):
https://github.com/rubocop/rubocop-rails#rails-configuration-tip
This means that the generated files will be formatted according to user's .rubocop.yml custom configuration.
## Detail
Since `bin/rails generate` and `bin/rubocop` are used only in the development environment,
the target files are limited to only `config/environments/development.rb`.
## Additional information
This feature was introduced in Rails 6.1 by https://github.com/rails/rails/pull/38870.
There are valid use cases for running SQLite in production, however it must be done
with care, so instead of a warning most users won't see anyway, it's preferable to
leave the configuration commented out to force them to think about having the database
on a persistent volume etc.
Co-Authored-By: Jacopo Beschi <beschi.jacopo@gmail.com>
This commit addresses the CI failure against Ruby master branch.
https://buildkite.com/rails/rails/builds/102575#018c4147-8760-48ac-812c-4e63fbe242fa
This failure reproduces since this commit:
d411d8f5fe
* Steps to reproduce
Install `ruby 3.3.0dev`
```ruby
git clone https://github.com/rails/rails
cd rails/railties
rm ../Gemfile.lock
bundle
bin/test test/application/bin_setup_test.rb -n test_bin_setup_output
```
* Without this commit
```ruby
$ ruby -v
ruby 3.3.0dev (2023-12-16T21:45:33Z master d7d10f3ee8) [x86_64-linux]
$ rm ../Gemfile.lock ; bundle ; bin/test test/application/bin_setup_test.rb -n test_bin_setup_output
... snip ...
F
Failure:
ApplicationTests::BinSetupTest#test_bin_setup_output [/home/yahonda/src/github.com/rails/rails/railties/test/application/bin_setup_test.rb:51]:
--- expected
+++ actual
@@ -2,10 +2,12 @@
The Gemfile's dependencies are satisfied
== Preparing database ==
+/home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/zeitwerk-2.6.12/lib/zeitwerk/kernel.rb:38: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec.
Created database 'app_development'
Created database 'app_test'
== Removing old logs and tempfiles ==
+/home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.3.0+0/gems/zeitwerk-2.6.12/lib/zeitwerk/kernel.rb:38: warning: mutex_m was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.4.0. Add mutex_m to your Gemfile or gemspec.
== Restarting application server ==
"
bin/test test/application/bin_setup_test.rb:30
Finished in 12.553516s, 0.0797 runs/s, 0.0797 assertions/s.
1 runs, 1 assertions, 1 failures, 0 errors, 0 skips
$
```
- ### Problem
If an application has configured a Broadcast Logger, setting the
`config.log_level` to any value has no effect:
```ruby
# config/application.rb
config.logger = ActiveSupport::BroadcastLogger.new(Logger.new(STDOUT))
config.log_level = :warn
puts Rails.logger.broadcasts.map(&:level) # => [Logger::DEBUG]
```
This is a side effect of #49621 which tried to fix the `log_level`
default value overriding the whole broadcasts.
### Context
The `log_level` default's value shouldn't apply to a Broadcast
Logger, as otherwise it overrides whatever the application
previously configured. While this behaviour is the same with
a vanilla logger, at least we can workaround it:
```ruby
# When using a vanilla logger
config.logger = Logger.new(STDOUT, level: LOGGER::WARN)
# Once the app boots, the level is overriden to DEBUG. We need to add the following line.
config.log_level = :warn
# When using a broadcast logger
stdout = Logger.new(STDOUT, level: Logger::INFO)
stderr = Logger.new(STDERR, level: Logger::ERROR)
config.logger = ActiveSupport::BroadcastLogger(stdout, stderr)
# Once the app boots the whole broadcast level is overriden to DEBUG.
# There is no way to workaround this as you can't fine grain the level of each
# loggers with `config.log_level=`.
```
### Solution
This PR ignores the default `log_level` value when using a Broadcast Logger,
but ensure it gets used if an application manually sets it.
Fix#50324
