The `ChatRelayJob` under "14.3 Custom Assertions And Testing Broadcasts Inside Other Components" defined a `perform_later` method, which I think should just be `perform`.
This allows applications to specify the maximum number of records that
will be destroyed in a single background job by the `dependent:
:destroy_async` association option. By default, the current behavior
will remain the same: when a parent record is destroyed, all dependent
records will be destroyed in a single background job. If the number of
dependent records is greater than this configuration, the records will
be destroyed in multiple background jobs.
At GitHub, we have a custom method for destroying associated records
in the background that we'd like to replace with
`dependent: :destroy_async`. Some associations have a large number of
dependent records, and our infrastructure requires that background jobs
complete quickly, so we limit the maximum number of dependent records
destroyed in a single background job and enqueue additional jobs when
the number of records exceeds that limit.
ImageProcessingTransformer now offers a configurable allow-list for
transformation methods in addition to a configurable deny-list for arguments.
[CVE-2022-21831]
One feature of the content security policy DSL, though undocumented,
is that it will not generate headers for non-HTML responses, even if a
configuration is explicitly provided. While it may not seem obvious
that anyone would want to send this header in an API response, Mozilla
Observatory, for instance, recommends the following for API responses:
`Content-Security-Policy: default-src 'none'; frame-ancestors 'none'`
(source: https://observatory.mozilla.org/faq/)
The Secure Headers gem also makes recommendations about the content
security policy for API responses: https://github.com/github/secure_headers#api-configurations
As such, this removes the HTML guard clause from the
`ContentSecurityPolicy` middleware.
Ref: https://github.com/rails/rails/pull/43625#discussion_r809532572
It can be used by error reporting service integration when they wish
to handle the error higher in the stack.
For instance Sidekiq has its own error handling interface with a
little bit of extra context information.
I am trying to find a sweet spot here.
Personally, not quite satisfied by having lib/action_cable/zeitwerk.rb. At the
same time, trying to avoid too taking much space in lib/action_cable.rb.
This patch also moves
require_relative "action_cable/version"
within ActionCable. Why? In a project, I like that the entrypoint defines the
namespace. That is the main file for that namespace.
Then, files below have it already created, and reopen it.
I just find this deliberate order of execution to be natural, hierarchical,
matching the project structure.
Otherwise it might only be loaded once `url_for` is called:
```
from bundler/gems/rails-5772ecd7d568/actionpack/lib/action_dispatch/routing/routes_proxy.rb:7:in `<module:Routing>'
from bundler/gems/rails-5772ecd7d568/actionpack/lib/action_dispatch/routing/routes_proxy.rb:6:in `<module:ActionDispatch>'
from bundler/gems/rails-5772ecd7d568/actionpack/lib/action_dispatch/routing/routes_proxy.rb:5:in `<main>'
from gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
from gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
from gems/zeitwerk-2.5.4/lib/zeitwerk/kernel.rb:35:in `require'
from bundler/gems/rails-5772ecd7d568/actionpack/lib/action_dispatch/routing/polymorphic_routes.rb:214:in `polymorphic_method'
from bundler/gems/rails-5772ecd7d568/actionpack/lib/action_dispatch/routing/polymorphic_routes.rb:116:in `polymorphic_url'
from bundler/gems/rails-5772ecd7d568/actionpack/lib/action_dispatch/routing/url_for.rb:187:in `full_url_for'
from bundler/gems/rails-5772ecd7d568/actionpack/lib/action_dispatch/routing/url_for.rb:170:in `url_for'
```
