This will greatly increase the visibility of Rails console commands and helpers,
and stop rely on IRB's internal components.
Extension API reference: https://github.com/ruby/irb/blob/master/EXTEND_IRB.md
And because we need to create new classes to use the new APIs, I also
moved all the IRB-specific code to a new file, `irb_console.rb`.
Use IRB.conf[:BACKTRACE_FILTER] for backtrace filtering in console
This change uses the new `IRB.conf[:BACKTRACE_FILTER]` to inject the backtrace
filtering logic into IRB. This avoids the need to patch IRB's internal
WorkSpace class.
Update changelog
rails/rails@957a3e5 allowed the BACKTRACE env to unsilence backtraces in normals runs not just tests. However, the implementation achieves this by removing the silences in an initializer. This means that the state of backtrace silencer becomes cached by spring and the developer needs to reset spring every time they want to silence or unsilence the backtrace. It also means custom silencers added in an initializer need to be added after the :configure_backtrace_cleaner initializer or else they won't be un-silenced properly.
Instead, let's teach Rails::BacktraceCleaner to unsilence the backtrace if the BACKTRACE variable is set. ActiveSupport::BacktraceCleaner#clean already allows this by passing nil as the second argument, which just filters but does not silence the backtrace. So, in Rails::BacktraceCleaner#clean we can call super with nil in the second argument if the BACKTRACE variable is present. That way we do not need to remove the silencers in an initializer, and we don't have to reset spring to silence the backtrace.
`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>
## Motivation / Background
An issue was identified where an error occurs when executing `apply_rubocop_autocorrect_after_generate!` with `--pretend` option,
according to feedback from https://github.com/rubocop/rubocop-rails/pull/1263.
## Details
This PR fixes the following error when executing `apply_rubocop_autocorrect_after_generate!` with `--pretend` option:
```console
$ bin/rails g migration create_users -p
```
### Before
An `Errno::ENOENT` error occurs:
```console
invoke active_record
create db/migrate/20240329060627_create_users.rb
/Users/koic/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/bundler/gems/rails-8e46af8c9396/railties/lib/rails/configuration.rb:138:in
`system': No such file or directory - bin/rubocop (Errno::ENOENT)
```
### After
No errors.
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
