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.
Extracted from: https://github.com/rails/rails/pull/50999
- Make fixtures setup and teardown methods private.
- Don't run adapter thread safety tests with sqlite3_mem
- Make foreign_key_tests more resilient to leaked state
- Use `exit!` in fork to avoid `at_exit` side effects.
- Disable transactional fixtures in tests that do a lot of low level
assertions on connections or connection pools.
The `create` method is currently marked as an alias of `new`. However,
because `new` is later overridden, it's no longer an alias.
This requires wrapping the `alias_method` with stopdoc/startdoc, as the
method is still marked as an alias otherwise (adding `:nodoc:` doesn't
help).
The `initialize` method has to be wrapped with stopdoc/startdoc as well,
as the `new` method will still be documented for the initialized.
Adding a `:nodoc:` instead will remove documentation for all following
methods.
All headers in a guide get a unique `dom_id` to make anchor links work.
If a header is already present we would prefix it with the `dom_id` of
the parent node. This would not work for headers without parent nodes.
This commit simplifies the `dom_id` uniqueness by only prepending the
parent node if it exists. This can still result in duplicates at the
same level, but for these we already show a warning:
*** DUPLICATE ID: 'some_id', please make sure that there are no
headings with the same name at the same level.
Co-authored-by: Carlos Antonio da Silva <carlosantoniodasilva@gmail.com>
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.
As well as `disconnect!` and `verify!`.
This generally isn't a big problem as connections must not be shared between
threads, but is required when running transactional tests or system tests
and could lead to a SEGV.
Extracted from: https://github.com/rails/rails/pull/50999
Some tests may use the connections in ways that cause the fixtures
transaction to be committed or rolled back. The typical case being
doing schema change query in MySQL, which automatically commits the
transaction. But ther eare more subtle cases.
The general idea here is to ensure our transaction is correctly
rolling back during teardown. If it fails, then we assume something
might have mutated some of the inserted fixtures, so we invalidate
the cache to ensure the next test will reset them.
This issue is particularly common in Active Record's own test suite
since transaction fixtures are enabled by default but we have
many tests create tables and such.
We could treat this case as an error, but since we can gracefully
recover from it, I don't think it's worth it.
`self.class` is a fairly narrow cache key, so it doesn't hit that much,
but more importantly, since nothing clears that cache, on large test
suites it keeps growing extremely large.
Using the list of fixtures as a cache key doesn't strictly solve
the growth issue, but most classes actually load all fixtures so
this should shrink the cache size considerably.
At the moment, Rails::Rack::Logger tags the logger (if it's
ActiveSupport::TaggedLogging) for the duration of the @app.call, but
only fires the request.action_dispatch event later, on body close. That
means anything logged in request.action_dispatch handlers won't have the
same tags as the rest of the request.
Fix this by deferring the popping of tags into
finish_request_instrumentation, in the same way that finishing the
instrumentation handle is deferred.
On my machine, running the whole Active Record test suite takes
`88` seconds, and `40` of these are spent in encryption tests.
Some of them also happen to flake because of random blips.
I appreciate the care that has been put into ensuring the overhead
of encrption was reasonable, but I don't think these tests justify
their cost.
Most of the time was spent waiting on the default 5 seconds
checkout timeout.
Reducing in for just these tests saves about 1 minute of run time
but more importantly saves me from trying to figure out if my
refactoring introduced a deadlock of some sort.
Before: `real 1m4.448s`
After: `real 0m6.395s`
This is invoked by Minitest before invoking the test, allowing
to print the test name in advance.
This is useful to debug slow and stuck tests by turning on verbose
mode. This way the stuck test name is printed before the process
deadlock.
Otherwise you have to resort to dirty tricks to figure out which
test is not returning.
This is also how the default Minitest reporter works in verbose
mode.
ActiveStorage::Filename was missing quotes when encoded,
generating invalid json like this -
```
JSON.generate(foo: ActiveStorage::Filename.new("bar.pdf") # => '{"foo":bar.pdf}'
```
Delete to_json and rely on the implementation from ActiveSupport::ToJsonWithActiveSupportEncoder
This change is an up-port of #50787 which applied a similar fix to 7-1-stable.
Since these tests weren't running before, we didn't notice when the DirectUploads controller tests were broken. My theory is that it has something to do with changing `response.parsed_body` to return a HWIA (in #49003).
This change is different from the 7-1-stable PR in that it removes the need to stringify or symbolize any keys, since we are comparing the metadata with string keys. This is a follow up to #43705.
Co-authored-by: Sean Doyle <seanpdoyle@users.noreply.github.com>
Co-authored-by: Jean byroot Boussier <jean.boussier+github@shopify.com>
Managed to reproduce CI failure at https://buildkite.com/rails/rails-nightly/builds/133#018d7bb8-8a32-4978-8e36-d7cb9b067813/1196-1204 . It would also reproduce against the released versions of Ruby because this is triggered by minitest v5.22.0 change. ebb468c81c
To avoid all of railties CI failures, pin minitest version to 5.21 tentatively.
* Steps to reproduce
```ruby
git clone https://github.com/rails/rails
cd rails
rm Gemfile.lock
bundle install
cd railties
bin/test test/application/test_runner_test.rb -n test_system_tests_are_not_run_with_the_default_test_command
```
* Expected behavior
It should pass.
* Actual behavior
```ruby
$ bin/test test/application/test_runner_test.rb -n test_system_tests_are_not_run_with_the_default_test_command
Run options: -n test_system_tests_are_not_run_with_the_default_test_command --seed 14574
F
Failure:
ApplicationTests::TestRunnerTest#test_system_tests_are_not_run_with_the_default_test_command [test/application/test_runner_test.rb:1191]:
Expected /0\ runs,\ 0\ assertions,\ 0\ failures,\ 0\ errors,\ 0\ skips/ to match "Nothing ran for filter: \nRunning 0 tests in a single process (parallelization threshold is 50)\nRun options: --seed 45713\n\n# Running:\n\n".
bin/test test/application/test_runner_test.rb:1179
Finished in 9.982314s, 0.1002 runs/s, 0.2004 assertions/s.
1 runs, 2 assertions, 1 failures, 0 errors, 0 skips
$
```
Followup: https://github.com/rails/rails/pull/50923
Instead of stopping on the first frame that isn't in
Action Dispatch, we should return the first frame that
isn't filtered by the backtrace cleaner.
The following was added to the `ActiveJob::Callbacks`,
`ActiveModel::Callbacks` and `AbstractController:Callbacks` docs
in #29072:
> NOTE: Calling the same callback multiple times will overwrite
> previous callback definitions.
The comment refers to "calling" callbacks but seems to be about defining
callbacks, as mentioned in the PR description.
In the ActiveJob and AbstractController docs, I believe this will be
misinterpreted as referring to setting callbacks, which, as far as I can
tell, does not have such a restriction.
In the ActiveModel docs, I believe it would be slightly clearer to
replace "calling" with "defining".
