DEV Community: Hassan Ahmed

Rails 7.1 Framework Defaults 🚧

Hassan Ahmed — Sun, 09 Nov 2025 19:37:29 +0000

I am already a bit late with this post but like one of my previous posts about enabling Rails 7 defaults, documenting the same procedure for 7_1 has been something on my todo list.

🚧

Since with 7_1 we have quite a few new framework defaults we need to go through and enable and since I want to keep all the information in one single post, I will be updating this blog post incrementally with information about more defaults periodically (weekly is the plan at least).

Disclaimer:

Before starting, I'd like to give a disclaimer, any change you make to your production application should always go through some pre prod screening/testing. I have tried to present some resources and information around the impact of these defaults, but there might be something I may have missed. If you find something, please do leave a comment so I can also update and learn. Thanks in advance for that and reading.

Rails.application.config.action_dispatch.default_headers

Purpose
The comment that comes with the new framework default files when upgrading to 7_1 also is self explanatory but to summarize again, enabling this would remove X-Download-Options default header which mostly serves only IE (seems like IE8 only). IE8 has not been supported for quite some time now as well.

Reference(s):
For further reading

Rails.application.config.action_controller.allow_deprecated_parameters_hash_equality = false

Previous value: nil
New value: false
Purpose:
To understand the impact of enabling this particular flag I had to go through some PRs on rails official repo and came across the following PR. The description of which provides an important hint towards a bug that exists with the deprecated behavior of comparing AC::Parameters with a Hash

Reads of the key with fetch (also delete, values_at) lead to all subsequent read operations of the key to return an array of raw Hashes.

The pull request further refers to another one (#44812) which previously added deprecation warning around this behavior.

Tips
To detect any negative side effects of untoggling this one can rely on CI pipeline and of course, deploying it to some pre prod environment and monitor post prod roll out as well.

Reference(s):
rails/rails #44826
rails/rails #44812

Active Record Encryption now uses SHA-256 as its hash digest algorithm.

Purpose
This one is also explained pretty well in the new framework defaults file. TLDR: Based on your previous configuration set the appropriate value of AR encryption to either SHA1 or SHA256. If you have no data encrypted via AR, use the latest configurations under 7_1.

Reference(s)
This is pretty well explained in the comments right above this flag.

Rails.application.config.active_record.run_commit_callbacks_on_first_saved_instances_in_transaction

Purpose
The PR introducing this change itself explains it really well along with an example.

TLDR

Before: within a transaction updating multiple instances referencing to the same record in db would only fire after_commit upon first update.

After: trigger the callback when internal state of the record within the transaction is likely to match the database value

Reference(s)
PR introducing the change

Rails.application.config.active_record.sqlite3_adapter_strict_strings_by_default = true

Purpose
First of all this is not relevant if you are not using SQLite.
It seems historically SQLite accepted double quoted strings as identifiers like column names and single quoted strings as string literals. Later double quoted strings were also permitted to be accepted as literal strings if they didn't match an identifier (a column name for example). So to avoid this confusion or running into unexpected issues you can uncomment this flag, which will impose a stricter convention by default i.e. single quotes = literal string, double quotes = identifiers

Reference(s)
Explained here

Rails.application.config.active_record.allow_deprecated_singular_associations_name = false

Purpose

Given you have a model structure like

class Book < ApplicationRecord
  belongs_to :author
end

You could do something like

Book.where(authors:....)

authors is pluralized in the above query but when looking from the perspective of model and relationship, a book can have a single author. There is more to this change, it comes with an underlying performance improvement as well. More details can be found on the provided references below. Uncommenting this flag, would now raise an error if you refer to a singular association in pluralized manner in your queries.

Tips
Once uncommented, if you have good test coverage, it will point out most of the areas where this change needs to be made, I'd do some manual scanning of codebase as well and of course some testing before merging this change.

References(s)

rails/rails PR#45452

Rails.application.config.active_job.use_big_decimal_serializer = true

Purpose
Background job adapters often store the payload of a job like its name and arguments supplied to it after serializing it to JSON. This comes with a small inconsistency that during this process of serializing to JSON, BigDecimal type of data is serialized to String. This can lead to unintended behavior or bugs when the said background job expecting BigDecimal ends up with String values.

Uncommenting this flag ensures, the BigDecimal values are serialized and fetched as their original datatype.

⚠️ As advised in the new_framework_defaults_7_1.rb.tt file, you need to make sure, your application and all possible replicas which will be effected by this change have been successfully upgraded to Rails 7_1.

Tips
Along with CI to report any inconsistencies or errors, I'd also take a look on what arguments the background jobs within the project expect to be extra sure before flipping this flag.

References

#45618

Rails.application.config.active_support.raise_on_invalid_cache_expiration_time = true

Purpose
Uncommenting this flag will raise an error if a cache expiration time of past was provided when caching some data. PR linked in references introducing this change (#45842) gives a very good idea of what to expect with this change.

References

#45842
Follow up PR #45892

Rails.application.config.active_record.query_log_tags_format = :sqlcommenter

Purpose
This default can be given two values :legacy(existing behaviour) or :sqlcommenter. Providing it the latter, will add additional context to the SQL queries generated from ActiveRecord which can be used for better observability and monitoring sources that trigger slow SQL queries.

will also try and some examples of the new vs old versions of logs

References

Rails.application.config.active_support.message_serializer = :json_allow_marshal

Purpose
Prior to 7_1, Rails used :marshal as serializer when using MessageEncryptor or MessageVerifier, which (as mentioned) is vulnerable to deserialization attacks. The proposed new value :json_allow_marshal instead uses :json serializer going forward but also can deserialize content previously serialized using :marshal (backwards compatible).

Important
As pointed out in #48170, going forward it will be changed to json only serializer.

References

Rails.application.config.active_support.use_message_serializer_for_metadata = true

Purpose
This change introduces an optimization in how messages are serialized, as mentioned in the attached PR rather than twice, messages are " URL-encoded only once".

As mentioned in the actual new_framework_defaults_7_1.rb, messages serialized in the old format can still be read after enabling this default, however, once enabled, message serialzed with this new format won't be readable if the flag is disabled again.

Important
Its also further recommended, if you are in process of bumping from 7 to version 7_1, first deploy the version update to your infrastructure with this flag disabled and then perform a subsequent deployment with this flag enabled.

References

#46848

Rails.application.config.log_file_size

Purpose
Pretty self explanatory, for test and development environment it sets a maximum size for the logfile to be 100 mb.

References

#44888

Rails.application.config.active_record.raise_on_assign_to_attr_readonly = true

Purpose
Once enabled, any attempt to assign any value to an attribute declared as readonly in the model will raise an error.

There are a few ways to also verify this does not results in new errors being thrown like

if there are no declaration of such attributes you are safe
if there are such attributes, if possible it would be worth checking if they are being updated
test coverage if done properly should also be able to point any regression in CI

References

#46105

To be continued....

Rails 7.1: Changes to $LOAD_PATH

Hassan Ahmed — Sun, 09 Mar 2025 13:34:03 +0000

Having worked in Ruby on Rails, you must know we don't need to manually require files that reside inside the app folder. The framework internally takes care of loading and reloading files in the app folder and apart from it, if we want to autoload any other folder e.g. lib, that can be achieved by pushing it to the collection config.autoload_paths (more details can be found in the guides). Historically, all autoload paths were pushed to $LOAD_PATH.

TLDR: $LOAD_PATH a.k.a $: is a collection of absolute paths that you can require (this video although a bit old helped me in understanding this concept better)

Starting Rails 7_1 autoloaded paths will no longer be added to $LOAD_PATH. Since autoloaded files e.g. app/models/user.rb are implicitly "required", it actually does makes sense to not bloat the $LOAD_PATH and it only contains list of paths that we need to require and are not handled by the autoloader.

If you are upgrading from a previous version of Rails this option was part of the new Rails 7_1 defaults under the flag

Rails.application.config.add_autoload_paths_to_load_path = false

Uncommenting this default will also no longer move the autoloaded paths to $LOAD_PATH.

Upgrading from a previous version
In terms of impact, if you just upgraded from a previous version of Rails, I assume for the most part it should be safe as autoloaded files should not be required in the first place and test coverage should point out if this can be a breaking change. Moreover, I'd test this first on a non prod environment by playing around the application a bit and later when shipped to prod, keep an eye on any errors that pop up.

Happy coding!

References:

Enabling Rails 7.0's New Framework Defaults

Hassan Ahmed — Sat, 18 May 2024 23:48:06 +0000

Recently I had a chance to enable Rails 7's new framework defaults, I thought I'd share the research and reasoning that I was able to extract for each of these via blog post.

Before you proceed:

This is not the complete list of the new Rails 7 defaults, there are a few missing, that I will try and document soon in this same blog.

Also I'd recommend, doing your own research along the way and suggest any improvements/corrections to this post as well.

Lets jump right into the new defaults then!

`Rails.application.config.action_view.button_to_generates_button_tag = true`

Uncommenting this default would now generate a button tag rather than an input tag of type submit in the from rendered by the button_to helper.

To Uncomment
This should be safe to uncomment if you are not using button_to helper. If you are, ideally test coverage should be in place to detect any unexpected behavior or you can also manually test if its feasible. There may be some slight change in behavior e.g if you are relying on some param being sent to the controller by the button_to helper prior to uncommenting this line.

`Rails.application.config.action_view.apply_stylesheet_media_default = false`

Uncommenting this line would mean the stylesheet html tags that are rendered by stylesheet_link_tag will no longer include the media attribute set to screen.

To Uncomment
Uncommenting this line would mean, style sheets will be applied to all media types unless you have explicitly specified media attribute on any. For safety you can check all the included stylesheets in your project and determine if you need to make any changes and then uncomment this line.

`Rails.application.config.active_support.hash_digest_class = OpenSSL::Digest::SHA256`

You may notice in the new_framework_defaults_7_0.rb file mentioning the impact of this change, which is cache invalidation.
In order to gather some more information I looked at the ActiveSupport::Digest which basically has just 3 class methods, a setter & getter for hash_digest_class and the hexdigest method. Furthermore, I searched across the rails/rails repo to find the usage of ActiveSupport#hex_digest_class (if interested this link leads to the search results) to find most of its usage only around code that deals with caching. This included caching of views, active_record queries, http ETAGs and also cache keys for the cache store you have set e.g. redis, filestore etc.

To Uncomment:
Uncommenting this would mean cache keys will now be read/generated using the new SHA::256 digest and existing cache keys will no longer be readable resulting in cache misses across all the impacted areas and resulting in new cache keys being generated using the new digest. This can mean a dip in performance initially for your application. Also, previously generated cache entries using SHA::1 will stay in the cache store you have configured until their expiration which may also mean some additional storage being consumed from your cache store for that time period.

`Rails.application.config.active_support.remove_deprecated_time_with_zone_name = true`

With this flag commented, ActiveSupport::TimeWithZone.name returned Time rather than the actual class name. Uncommenting this flag will return the actual class name rather than this overridden implementation.

To Uncomment
If you are not using ActiveSupport::TimeWithZone.name anywhere in your codebase, this should be safe to uncomment. If you are, you may have to handle those cases accordingly or disable this default in the application.rb, whatever works for your case.

`Rails.application.config.active_support.cache_format_version = 7.0`

Rails 7 introduces a more optimized serialization format for caching. This new format should be able to read cache entries that were serialized with Rails 6.1 but, Rails 6.1 will not be able to read the entries serialized using this new format so only enable this flag after you don't plan to move back to using a previous Rails version.
Refer to this pull request if you are interested in knowing more details about the implementation.

To Uncomment
As long as you have no plans to move back to Rails 6.1, you can safely enable this flag, as mentioned, cache entries serialized by 6.1 should be read by the new format as well.

Update
It seems to enable this flag, you need to set it in application.rb (pull request for reference) as later an issue was raised highlighting that merely uncommenting this flag did not make the app use the newer cache format. You can verify yourself as well the behaviour in console by using

Rails.cache.instance_variable_get(:@coder) 
# and check whether the returned value is ActiveSupport::Cache::Coders::Rails70Coder or ActiveSupport::Cache::Coders::Rails61Coder

`Rails.application.config.active_support.executor_around_test_case = true`

Looking at this PR to extract more details around this default, it looks like it should be relatively safe to uncomment it. This will allow data like Current Attributes to be reset after each request, even if there are multiple requests within a single test. (the following test case also gives some idea).

To Uncomment
If the build is green then it shouldn't be much of an issue in my opinion.

`Rails.application.config.active_support.isolation_level = :thread`

Quoting the comment next to this default

If you use a fiber based server or job processor, you should set it to :fiber.
Otherwise the default of :thread if preferable.

This description seems pretty clear in terms of what value should be set. In case you are using a thread based server like puma and a thread based job processor like Sidekiq you can uncomment this default.

`Rails.application.config.action_mailer.smtp_timeout = 5`

Sets the default timeout value for SMTP requests so that unfulfilled requests are timedout.

To Uncomment
I don't anticipate any regression coming out of uncommenting this default, the way I enabled this was to test some emails on a staging environments and all seemed to work and then closely monitor the bug tracking system of any timeouts.

`Rails.application.config.active_record.verify_foreign_keys_for_fixtures = true`

Quoting the changelog entry from rails 7 stable version

Tests will not run if there is a foreign key constraint violation in your fixture data.
The feature is supported by SQLite and PostgreSQL, other adapters can also add support for it.

To Uncomment
If you are not using fixtures for your specs, this might have no impact at all for you. If you are, uncommenting this should raise the foreign key violations that you will have to fix.

`Rails.application.config.action_controller.raise_on_open_redirects = true`

To prevent open redirect attacks, uncommenting this default will raise an error whenever redirect_to or redirect_back redirects to a different host.

To Uncomment
In my opinion having a good test coverage is important for this one, once uncommented (if there is proper test coverage), it should be able to highlight the areas from where external redirection is taking place. If its necessary to keep the redirection you can permit it by using allow_other_host option in those places. You can also search your codebase for redirect_to or redirect_back to see whether at any of those places you are redirecting to an external host.

`Rails.application.config.action_controller.wrap_parameters_by_default = true`

Your Rails application may have an initializer by the name of wrap_parameters.rb with similar content. The purpose of this functionality is to wrap parameters sent to a controller in a nested hash. For example and further reading please refer to this page from docs (v6).

To Uncomment
If you haven't made any changes to the wrap_parameters initializer, this default is safe to uncomment, otherwise you can keep on using the customized version of your initializer and disable this default in application.rb.

`Rails.application.config.active_support.use_rfc4122_namespaced_uuids = true`

Can safely be uncommented if you are not using any of the methods from Digest::UUID in your codebase.

From what I could gather after going through the changes in the mentioned PR (below), it fixes behavior of generating UUIDs when provided namespace is different from the ones defined in the class.

Reference PR

`Rails.application.config.action_dispatch.default_headers`

This default changes the X-XSS-Protection response header's value to 0 which means disabling it in favor of CSP (Content Security Policy). It seems almost all major browser no longer support this header due to some of the vulnerabilities it came with.

PR for more details.

To Uncomment
Its always good to have an effective CSP for your application, I'd recommend to create one if you haven't for your app before uncommenting this default.

Thanks for reading, if you have some feedback or want to suggest some correction, please feel free to share those in the comments below.

Programming bliss to you!!

Database Pool Management with Sidekiq and load_async

Hassan Ahmed — Sun, 14 Apr 2024 22:04:57 +0000

Recently I came across a very common issue after integrating a few Sidekiq jobs to a project.

During this activity, I set the pool size in database.yml of the worker process equal to the concurrency I set for Sidekiq. Its recommended to have pool size equal to or greater than the concurrency setting otherwise, you can run into issues or even if there are no apparent errors, this will likely cause additional latency in the queues.

But strangely, I still ran into this error:

ActiveRecord::ConnectionTimeoutError <background job name>

could not obtain a connection from the pool within 5.000 seconds (waited 5.062 seconds); all pooled connections were in use

As the error suggests, the worker thread executing the job attempted to obtain a database connection but was not able to and after waiting for 5 seconds raised this exception.

Possible Reason??

In my case, the issue was not as straight forward as the pool size being less than the total concurrency set for Sidekiq.

load_async

I searched for the codebase for Thread.new initially to see if there are any queries being executed in separate threads in any of the jobs, but the only occurrences I came across were not relevant.
Secondly I looked for load_async (which basically queries database asynchronously details) and actually found it being used by one of the classes that was being instantiated and used in one of the background jobs.

And that was it, despite having a pool value equal to the concurrency that I have set in Sidekiq, having load_async in one of the jobs meant, this was an additional (unaccounted) thread that can consume a connection from the pool causing another thread to wait.

With the root cause of the issue established, I adjusted my pool size for the worker process (in database.yml) as recommended here

pool = total_concurrency + global_executor_concurrency + 1

Where global_executor_concurrency refers to the number of asynchronous queries that can be executed concurrently and its default value is 4.

Which meant for me, the eventual value of the pool size I set was

pool = total_concurrency + 4 + 1

For me this was an interesting finding and hope it helps and save some time for you if you come across similar scenario.

Happy Coding!

Migrating attachments to ActiveStorage on the go.

Hassan Ahmed — Sat, 27 Jan 2024 20:33:40 +0000

Background

A little while back, the team I was part of was tasked with migrating attachments from carrier_wave to active_storage. Basically the original task was to migrate the storage location of the files for the project that was originally configured to use carrier_wave.

This felt like a good opportunity to also migrate from using carrier_wave to active_storage since our application was already up to date with relatively recent rails version at the time and a solution provided out of the box from the framework makes more sense to use rather than relying on third party dependencies. Not to mention gems like carrierwave and paperclip have been the goto solution and rock solid for years before active_storage was introduced.

Possible Solutions 💡

Looking up online for similar case studies (migrate from carrier_wave/paperclip to active_storage), I found a number of very helpful articles explaining in detail how to achieve this, a common approach I observed was to do the migration in one go via some dedicated rake task or db migration. In our case due to some constraints it wasn't feasible for us to have a single long running task to migrate all existing attachments.

Considering these constraints we eventually decided to go with a different approach, perform the migration on the go. More precisely, migrate an attachment when its referenced from the codebase.

The final flow of events that we came up with looked something like this:

For new uploads:
This case was simple enough, new uploads will be uploaded via active_storage.

For existing uploads
For existing uploads, we devised this sequence of events:

Check if the requested attachment exists on active_storage
if yes, return the attachment from active_storage
if no, enqueue a job to attach the requested attachment to active_storage and in the meantime return the carrierwave attachment

Implementation 💻

Since I worked on this use case approximately a year ago, I will try and reconstruct the bits that I think are relevant and present those in the form of some pseudo implementation just to give an idea of the approach. I assume you will have active storage enabled already in your projects by this point.

However, if you want to ask a question specific to your use case please share those in the comment, I will try my best to guide you.

For the sake of this example lets take a simple use case where we have a Profile model having an attachment by the name of profile_picture.

The model will look something like this:

class Profile < ApplicationRecord
  mount_uploader :profile_picture, ProfilePictureUploader
end

1. Enable ActiveStorage

Firstly, we prepare our model to accept incoming attachments via active_storage.

class Profile < ApplicationRecord
  mount_uploader :profile_picture, ProfilePictureUploader
  has_one_attached :as_profile_picture # temporary alias used which will be removed later
end

This should allow us to enable attaching files to an instance of profile via as_profile_picture using active_storage. The name as_profile_picture is a temporary alias for now to avoid naming conflicts and will be later changed as a part of the clean up.

Note

Something I'd do at this point is also to change any strong params or any code where a profile_picture is assigned to an instance of Profile. That should already allow us to take care of one part of the problem which is to upload new attachments to active_storage.

Also create some sort of helper methods for example one good case to have a helper method would be to return the URL of the attachment for preview purposes based on the attachment type e.g. is_a?(ActiveStorage::Attachment) or is_a?(CarrierWave::Uploader).

2. Handling existing attachments

For existing attachments we'll attach them one at a time asynchronously to active_storage. Having carrier_wave uploader already mounted on the model we have access to the getter profile_picture that we have already been using to access the respective attachment. We can override it slightly to also achieve the second objective which was to migrate existing attachment to active_storage. Theoretically, that would mean doing something like this:

class Profile < ApplicationRecord
  mount_uploader :profile_picture, ProfilePictureUploader
  has_one_attached :as_profile_picture

  def profile_picture
    if as_profile_picture.attached?
      as_profile_picture
    else
      enqueue_attachment_migration("profile_picture")
      super
    end
  end

  private

  def enqueue_attachment_migration(attachment_name)
    MigrateAttachmentToActiveStorageJob.perform_async(id, class.name, attachment_name)
  end
end

As described in the diagram above with the latest changes we are able to now (for existing attachments):

Check if they exist on active_storage
If yes, just return the attachment from active_storage
If no, return the attachment via carrier_wave and enqueue a background job to attach the profile_picture to the instance via active_storage as well.

Background Job

The background job essentially fetches the file currently attached via carrier_wave and attaches it to the as_profile_picture association.

With these changes in place, this would take care of the second part of the use case we are trying to solve i.e. migrate existing attachments on the go asynchronously.

Post Migration Clean Up 🧹

Once we are sure that all the attachments that were meant to be migrated have been successfully migrated we can perform some clean up and change the temporary alias we had declared in the model to track active_storage attachments.

Database Clean Up

Just a heads up before moving forward, I wasn't able to execute this part but will share some ideas about the clean up that can be done after all the attachments have been migrated.

The names given to the attachments in the model, in our case as_profile_picture are tracked in the name column of the active_storage_attachment table. We will need to write a script to update the column values from as_profile_picture to profile_picture.

Model Clean Up

Once we have updated the names in the active_storage_attachments we can clean up some of the code we added earlier in the model to be something like:

class Profile < ApplicationRecord
  has_one_attached :as_profile_picture
end

And if everything works we can even go and remove the Uploader classes and carrier_wave related attributes from the database schema.

Note

At this point, I would also clean up/refactor the helper methods added accordingly e.g. removing any conditional behavior based on whether attachment was previously stored via carrier_wave or active_storage.

Conclusion

To conclude I wanted to sum up what I thought was a newer perspective when it came to data migration, the idea behind writing this post was to present with an alternate idea for anyone looking for options.

The code samples are just to give an idea, I initially felt working with a live project for this post but due to time constraint I wasn't able to. Also, I think active_storage in terms of setup and configuration is well documented on a number of forums.

Hope this was of some help for you, if you have questions or feedback feel free to share those in the comments.