ActiveSupport::CurrentAttributes provides a thread-isolated attributes singleton #29180

dhh · 2017-05-22T10:20:40Z

Abstract super class that provides a thread-isolated attributes singleton.
Primary use case is keeping all the per-request attributes easily available to the whole system.

The following full app-like example demonstrates how to use a Current class to
facilitate easy access to the global, per-request attributes without passing them deeply
around everywhere:

# app/models/current.rb
class Current < ActiveSupport::CurrentAttributes
  attribute :account, :user
  attribute :request_id, :user_agent, :ip_address 
  
  resets { Time.zone = nil }
  
  def user=(user)
    super
    self.account = user.account
    Time.zone = user.time_zone
  end
end

# app/controllers/concerns/authentication.rb
module Authentication
  extend ActiveSupport::Concern

  included do
    before_action :set_current_authenticated_user
  end

  private
    def set_current_authenticated_user
      Current.user = User.find(cookies.signed[:user_id])
    end
end

# app/controllers/concerns/set_current_request_details.rb
module SetCurrentRequestDetails
  extend ActiveSupport::Concern

  included do
    before_action do
      Current.request_id = request.uuid
      Current.user_agent = request.user_agent
      Current.ip_address = request.ip
    end
  end
end  

class ApplicationController < ActionController::Base
  include Authentication
  include SetCurrentRequestDetails
end

class MessagesController < ApplicationController
  def create
    Current.account.messages.create(message_params)
  end
end

class Message < ApplicationRecord
  belongs_to :creator, default: -> { Current.user }
  after_create { |message| Event.create(record: message) }
end

class Event < ApplicationRecord
  before_create do
    self.request_id = Current.request_id
    self.user_agent = Current.user_agent
    self.ip_address = Current.ip_address
  end
end

A word of caution: It's easy to overdo a global singleton like Current and tangle your model as a result.
Current should only be used for a few, top-level globals, like account, user, and request details.
The attributes stuck in Current should be used by more or less all actions on all requests. If you start
sticking controller-specific attributes in there, you're going to create a mess.

…ributes singleton

kaspth

Some minor details, but 👍 on the concept.

kaspth · 2017-05-22T15:43:42Z

activesupport/test/current_attributes_test.rb

+  end
+
+  def person=(person)
+    attributes[:person] = person


Reading this I'd think super would just work here. Should we make that work or too much of a hassle?

Do take a swing and see what contortions are needed, if you'd like 👍

Actually, not sure about that. We declare the attributes in the same class. They didn't come from super. I think super is too clever.

We make it work in AR/AMo, where they similarly belong to the current class.

It just means that instead of defining the built-in methods in the class directly, we put them into an anonymous module included for that purpose.

It's cleverer than we need to be, but I think it's simple enough that it's worth the gain in "do what I mean" expressiveness. It'll help people who do expect it to work, and I can't think of any way it'd manage to unpleasantly surprise someone who doesn't.

Pushed a commit for this. Opted to not define the singleton methods within the module, since those should just be left be by users.

kaspth · 2017-05-22T15:44:46Z

activesupport/test/current_attributes_test.rb

+Person = Struct.new(:name, :time_zone)
+
+class Current < ActiveSupport::CurrentAttributes
+  attribute :world, :account, :person


Could this be conflated with attribute from Active Model and Active Record?

It's the same concept, so I think it's good that it's using the same name.

I still think we could confuse people into thinking that the Active Model attributes type casting stuff is available here.

So since these are mostly attributes in name only — there's no dirty tracking, aliasing or other goodies from Active Model — perhaps we should just think of them as accessors?

class Current < ActiveSupport::CurrentAccessors accesses :world, :account, :person # Or maybe even `attr_accessor`? end

kaspth · 2017-05-22T15:45:10Z

activesupport/test/current_attributes_test.rb

+
+Person = Struct.new(:name, :time_zone)
+
+class Current < ActiveSupport::CurrentAttributes


Should we namespace this and Person so it won't clash with other tests?

kaspth · 2017-05-22T15:47:10Z

activesupport/lib/active_support/current_attributes.rb

+    #       end
+    #     end
+    #   end
+    def expose(exposed_attributes)


Perhaps make this **exposed_attributes so we get the type features for free (and the method won't NoMethodError on keys.

On the other hand why not just do this:

def expose(exposed_attributes) old_attributes, @attributes = @attributes, exposed_attributes yield ensure @attributes = old_attributes end

If we don't call the writers, we don't trigger stuff like Time.zone =.

matthewd · 2017-05-22T16:32:53Z

activesupport/lib/active_support/current_attributes.rb

+  # around everywhere:
+  #
+  #   # app/services/current.rb
+  #   require 'active_support/current_attributes'


active_support/all should include this, so the require won't be necessary.

I just set CurrentAttributes up as an autoload in the top level active_support.rb mirroring ActiveSupport::Concern.

cristianbica · 2017-05-22T19:19:53Z

Since thread_mattr_accessor appeared I'm using something like:

module Current
  thread_mattr_accessor :user

  module_function
    def reset
      Current.user = nil
    end
end

and in controllers I'm doing the hygiene:

class ApplicationController < ActionController::Base
  around_action :reset_current

  def reset_current
    Current.reset
    yield
  ensure
    Current.reset
  end
end

What would be nice is if we provide a fire-and-forget functionality which will do the resetting for each request. I'm thinking either a class flag (resets_on_action_controller_request ... or similar) or a subclass in actionpack (ActionController::CurrentRequestAttributes). Implementation-wise I would subscribe to start_processing.action_controller and process_action.action_controller.

Thus they won't conflict with other Current and Person stubs.

kaspth · 2017-05-22T19:53:02Z

@dhh was toying with the idea of generating app/services/current.rb by default. But we'd most likely just generate an app/controllers/concerns/current/reset.rb auto included in ApplicationController and a setup { Current.reset } in test_helper.rb, rather than hooking into log subscribing.

matthewd · 2017-05-22T19:55:36Z

I believe we'll be able to reset fully automatically through the executor.

kaspth · 2017-05-22T19:57:21Z

@matthewd ahh, right, of course!

kaspth · 2017-05-22T20:03:06Z

Right, we could keep track of the subclasses:

class ActiveSupport::CurrentAttributes
  mattr_accessor(:subclasses) { [] }

  class << self
    def inherited(subclass)
      subclasses << subclass
    end

    def reset_all
      subclasses.each(&:reset)
    end
  end
end

Then schedule an ActiveSupport::CurrentAttributes.reset_all executor hook in Active Support's railtie.

Define instance level accessors in an included module such that `super` in an overriden accessor works, akin to Active Model.

Follow the example of concerns, autoload in the top level Active Support file.

maclover7 · 2017-05-24T23:36:32Z

Two quick things:

This seems like something that is fairly app specific, and something that could live in a gem/outside of core elsewhere. As a sidenote to this, I'm more in favor of current_user and similar controller methods, rather than this globals approach.
Is the idea to provide an API similar to that of the Active Record attributes API? I think using the attribute macro might trip people up.

guilleiguaran · 2017-05-25T01:11:32Z

I'm more in favor of current_user and similar controller methods, rather than this globals approach

I think both approach aren't incompatible at all, in the app I'm working currently we have current_user and similar controller methods but we have a couple of globals depending on the location (e.g Region.current) of the user making the request and many business rules depending on this. We reference those globals in many models, views, controllers, helpers, mailers, concerns and using the global definitely makes the code cleaner than passing the current_region around all the classes of the stack.

As @dhh said this should be used carefully and in a few cases.

guilleiguaran

👍 but would like to see the recommendation by @matthewd / @kaspth in #29180 (comment) done before of merge

dhh · 2017-05-25T16:54:41Z

When does that executor run? Want to make sure we're clearing both before and after a request starts, just to ensure nothing is leaking anywhere.

Also, I think we can make it explicit that a CurrentAttributes class participates in this auto-resetting scheme. Maybe just have resets_on_request or something like that that adds it to the auto reset pool.

dhh · 2017-05-25T16:56:07Z

Jon,

I don't see anything app specific about tracking current user/account/region/request_id. Every app I've worked on has had some homegrown way of doing this.
Attribute is a generic name, like Object. I don't think there's any expectation of that having a global definition based on an implementation in AR.

cristianbica · 2017-05-25T16:58:26Z

@dhh executor runs before and after the request in a middleware

cristianbica · 2017-05-25T17:15:28Z

@dhh IMO this is great addition to the framework. I'm using everywhere class Current and thread_mattr_accessor but I need to do the cleanup in controllers.
As probably @maclover7 is trying to say there are some features that I believe are too much. The parts that I don't think I'm going to use are:

bidelegate ... I don't any real usage for it; I wouldn't instantiate the Current class; I would even add a delegate_missing_to :instance and create the attributes methods only on the instance
set ... I don't have a use case for it; Plus I would remove your example with using Current in jobs :)
resets callbacks; seems overkill for the object. A reset method that people can override in subclasses and call super should be more than enough. Callbacks are useful if people want to have the opportunity to act on reset from outside the object.

Skips the need for users to actively embed something that resets their CurrentAttributes instances.

kaspth · 2017-05-25T17:49:49Z

railties/test/application/current_attributes_integration_test.rb

+  test "current customer is assigned and cleared" do
+    get "/customers/set_current_customer"
+    assert_equal 200, last_response.status
+    assert_match(/david, Copenhagen/, last_response.body)


It would be nice if I could figure out how to test that the customer and Time.zone is reset after the request as well. Any bright ideas? 😄

Also remove the stale puts debugging.

kaspth · 2017-05-26T06:34:03Z

Got the auto-reset setup!

One thing that bothers me about CurrentAttributes is that they aren't attributes in the Active Model sense, there's no dirty tracking, aliasing etc. It's true they're roughly the same concept, so some overlap is warranted.

But these attributes are more purely about broadening the places where they're accessible within an app. They're accessors.

How about:

class Current < ActiveSupport::CurrentAccessors
  accesses :world, :account, :person # Or maybe even `attr_accessor`?
end

…ent-attributes

dhh · 2017-05-26T11:16:25Z

Awesome, @kaspth! The attributes thing doesn't bother me the slightest. Accessors is just beating around the bush, and imo less clear. Ruby itself uses attr_accessor, which is short for attribute_accessor. Here, we're actually declaring the attributes.

Anyway, this is all looking good to ship. I'll update the docs and merge. Much appreciate the API debate and the implementation upgrades 🙏👏🎉

bogdanvlviv · 2017-05-26T12:13:08Z

railties/test/application/current_attributes_integration_test.rb

+  setup do
+    build_app
+
+    app_file "app/services/current.rb", <<-RUBY


For consistency

-app_file "app/services/current.rb", <<-RUBY +app_file "app/models/current.rb", <<-RUBY

https://github.com/rails/rails/pull/29180/files#diff-3c3c0f647bc4702f9453c173a707aa06R10

bogdanvlviv · 2017-05-26T13:35:08Z

activesupport/lib/active_support/current_attributes.rb

+      end
+
+      def compute_attributes(keys)
+        keys.collect { |key| [ key, public_send(key) ] }.to_h


-keys.collect { |key| [ key, public_send(key) ] }.to_h +keys.collect { |key, _| [ key, public_send(key) ] }.to_h

Why? We're iterating over just an array of the keys, not a full hash.

Oh, sorry I just now saw https://github.com/rails/rails/pull/29180/files#diff-3c3c0f647bc4702f9453c173a707aa06R167

kaspth · 2017-05-27T12:31:48Z

Ruby itself uses attr_accessor, which is short for attribute_accessor

Ah yeah, good point. 👍 on sticking with attribute.

I noticed that storing instances in Thread.current means CurrentAttributes can't support dev reloading. I'm looking into clearing those on a reload to support that.

clairity · 2017-06-17T18:59:47Z

@kaspth do you have any idea on timeline for this feature to be released? i'm currently using a hacky homegrown implementation that i'd love to replace right away with this implementation (especially since i'm working on some related changes in my codebase right now).

kaspth · 2017-06-19T12:10:37Z

Rails 5.2 sometime this year.

radar · 2017-06-22T04:57:58Z

I am very opposed to this feature but after what happened last time I opposed a change on Rails I am not willing to fight this fight. It is a massive footgun and you're doing a massive disservice to the framework to introduce a global state.

Instead, I have stated my case in a blog post: http://ryanbigg.com/2017/06/current-considered-harmful. Afterall, this is what DHH encouraged last time.

If you really want to add oomph to the outrage engine, you could also post a medium article about how this is making you consider not using Rails (or was the final straw that made you leave). Both are popular choices for discharging bile, and I encourage them over reopening old tickets.

Choose to interpret it as bile if you wish. I meant it in a well-meaning fashion. Everyone's entitled to their own opinions, right?

dhh · 2017-06-22T07:19:06Z

A blog post is a great outlet to provide a different take on Current. Thanks for taking the time to write it up. I disagree with most of what's written, and found the "DHH just did this! 😱" pretty hilarious, but good to have a different take. This pattern is used by Basecamp, GitHub, Shopify, and many others. It's not a new invention, but an extraction. Like almost all features in Rails. Anyway, as always, you're free to decline the unagi. We can enjoy the rest of the menu together.

…

On Jun 22, 2017, at 06:58, Ryan Bigg ***@***.***> wrote: I am very opposed to this feature but after what happened last time I opposed a change on Rails I am not willing to fight this fight. Instead, I have stated my case in a blog post: http://ryanbigg.com/2017/06/current-considered-harmful. I will not enter into any more discussion on this. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

zernie · 2017-06-24T00:03:38Z

@dhh I agree that we can enjoy the rest of the menu together. But it's the overall direction of the framework that a lot of people are worried about; meanwhile the rest of the programming community shies away from bad design patterns, Rails happily embraces them.

dhh · 2017-06-24T06:28:17Z

Rails has been embracing patterns that some people consider to be "bad" since inception, yet we are somehow still here and in better shape than ever. I'm going to go with yesterday's weather and predict that the inclusion of Current will not change that conclusion one iota either.

Anyway, enjoy the rest of the menu!

ahazem · 2017-07-07T14:16:15Z

@clairity We have extracted the feature into a gem: https://github.com/coup-mobility/activesupport-current_attributes. Can be used with Rails >= 4.2.

dhh · 2017-07-07T14:23:29Z

Thanks, Ahmed! Please retain the original copyright in the license file.

…

On Fri, Jul 7, 2017 at 4:17 PM, Ahmed Hazem ***@***.***> wrote: @clairity <https://github.com/clairity> We have extracted the feature into a gem: https://github.com/coup-mobility/activesupport- current_attributes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29180 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAKtYwnK8LA_FwTCiOUzfdzGejEvhDKks5sLj3jgaJpZM4NiKMV> .

clairity · 2017-07-07T19:42:17Z

yes thanks @ahazem! i dropped it into my app and it's looking good so far!

rafaelfranca · 2017-07-07T20:52:11Z

I opened an issue to track the required license change in that gem https://github.com/coup-mobility/activesupport-current_attributes/issues/2

pavel-jurasek · 2017-07-07T22:14:23Z

@rafaelfranca @dhh please check https://github.com/coup-mobility/activesupport-current_attributes/commit/1cd6ffc0cfed385e2385c26e68e6403db4039ffa this commit should fix copyright issue please just confirm!

ahazem · 2017-07-07T22:51:17Z

@dhh Thanks for the pointer! The license file was auto-generated by bundler gem, which picked up my name from git config. We have updated the file.

@clairity Glad you find it helpful. :)

kaspth · 2017-07-09T15:21:14Z

@ahazem you might want to pull in its latest incarnation from the master branch. I've made some extra commits since merge. https://github.com/rails/rails/commits/master/activesupport/lib/active_support/current_attributes.rb :)

ahazem · 2017-07-10T07:49:01Z

@kaspth Nice, will pull them in! Thanks for pointing that out.

See http://edgeapi.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html Also: rails/rails#29180

Add ActiveSupport::CurrentAttributes to provide a thread-isolated att…

00c946b

…ributes singleton

dhh added the activesupport label May 22, 2017

dhh added this to the 5.2.0 milestone May 22, 2017

dhh added 2 commits May 22, 2017 12:20

Merge branch 'master' into current-attributes

05bd95c

Need to require first

0bf8a54

kaspth approved these changes May 22, 2017

View reviewed changes

matthewd reviewed May 22, 2017

View reviewed changes

kaspth added 2 commits May 22, 2017 21:23

Move stubs into test namespace.

be6c9dc

Thus they won't conflict with other Current and Person stubs.

End of the line for you, whitespace!

e4dac08

kaspth added 2 commits May 22, 2017 22:29

Support super in attribute methods.

ba427d0

Define instance level accessors in an included module such that `super` in an overriden accessor works, akin to Active Model.

Spare users the manual require.

a2e8717

Follow the example of concerns, autoload in the top level Active Support file.

kaspth force-pushed the current-attributes branch from e7e8c93 to a2e8717 Compare May 22, 2017 20:31

dhh added 2 commits May 23, 2017 13:34

Add bidelegation support

342aa4a

Rename #expose to #set. Simpler, clearer

bec220b

guilleiguaran approved these changes May 25, 2017

View reviewed changes

kaspth mentioned this pull request May 25, 2017

Make secrets:edit run secrets:setup if it hasn't already. #29195

Merged

1 task

Merge branch 'master' into current-attributes

00ecd7e

Automatically reset every instance.

08471e1

Skips the need for users to actively embed something that resets their CurrentAttributes instances.

kaspth reviewed May 25, 2017

View reviewed changes

Properly test resetting after execution cycle.

7db3ca8

Also remove the stale puts debugging.

Merge branch 'current-attributes' of github.com:rails/rails into curr…

16235c9

…ent-attributes

dhh added 2 commits May 26, 2017 13:26

Update documentation to match new autoreset

497d4c8

Merge branch 'master' into current-attributes

156a506

bogdanvlviv reviewed May 26, 2017

View reviewed changes

dhh merged commit 24a8644 into master May 26, 2017

dhh deleted the current-attributes branch May 26, 2017 18:00

kaspth mentioned this pull request Feb 24, 2018

Make RequestId globally available #5176

Closed

dannysmith added a commit to dannysmith/jimmy that referenced this pull request Mar 7, 2018

Add Current class

b606df1

See http://edgeapi.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html Also: rails/rails#29180

deivid-rodriguez mentioned this pull request Jul 5, 2018

AJAX authorization modals decidim/decidim#3753

Merged

4 tasks

bdewater mentioned this pull request Nov 7, 2020

Add ActiveSupport::CurrentAttributes to suggestions covermymeds/rubocop-thread_safety#39

Merged

huacnlee mentioned this pull request Dec 3, 2020

Use ActiveSupport::CurrentAttributes instead of the request_store for storage request cache huacnlee/rails-settings-cached#199

Merged


		Person = Struct.new(:name, :time_zone)

		class Current < ActiveSupport::CurrentAttributes

ActiveSupport::CurrentAttributes provides a thread-isolated attributes singleton #29180

ActiveSupport::CurrentAttributes provides a thread-isolated attributes singleton #29180

Conversation

dhh commented May 22, 2017 • edited

kaspth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaspth May 22, 2017 • edited

Choose a reason for hiding this comment

cristianbica commented May 22, 2017

kaspth commented May 22, 2017

matthewd commented May 22, 2017

kaspth commented May 22, 2017

kaspth commented May 22, 2017 • edited

maclover7 commented May 24, 2017

guilleiguaran commented May 25, 2017 • edited

guilleiguaran left a comment • edited

Choose a reason for hiding this comment

dhh commented May 25, 2017

dhh commented May 25, 2017

cristianbica commented May 25, 2017 • edited

cristianbica commented May 25, 2017

Choose a reason for hiding this comment

kaspth commented May 26, 2017

dhh commented May 26, 2017

bogdanvlviv May 26, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaspth commented May 27, 2017 • edited

clairity commented Jun 17, 2017

kaspth commented Jun 19, 2017

radar commented Jun 22, 2017 • edited

dhh commented Jun 22, 2017 via email

zernie commented Jun 24, 2017

dhh commented Jun 24, 2017

ahazem commented Jul 7, 2017 • edited

dhh commented Jul 7, 2017 via email

clairity commented Jul 7, 2017

rafaelfranca commented Jul 7, 2017

pavel-jurasek commented Jul 7, 2017

ahazem commented Jul 7, 2017 • edited

kaspth commented Jul 9, 2017

ahazem commented Jul 10, 2017

dhh commented May 22, 2017 •

edited

kaspth May 22, 2017 •

edited

kaspth commented May 22, 2017 •

edited

guilleiguaran commented May 25, 2017 •

edited

guilleiguaran left a comment •

edited

cristianbica commented May 25, 2017 •

edited

bogdanvlviv May 26, 2017 •

edited

kaspth commented May 27, 2017 •

edited

radar commented Jun 22, 2017 •

edited

ahazem commented Jul 7, 2017 •

edited

ahazem commented Jul 7, 2017 •

edited