ActiveSupport::CurrentAttributes gets reset in console #415
Comments
|
This does seem quite strange. Is it definitely the same behaviour if you use the plain class I just tried to reproduce this in a minimal way and was unable to.
# frozen_string_literal: true
source "https://rubygems.org"
gem 'que'
gem 'rails'
gem 'pg'
#!/usr/bin/env ruby
# Run with:
# bundle
# docker run -e POSTGRES_PASSWORD=que -e POSTGRES_USER=que -e POSTGRES_DB=que -p 5432:5432 -d postgres:14.7
# DATABASE_URL=postgres://que:que@localhost:5432/que bundle exec ./test.rb
require 'active_support'
require 'active_record'
require 'que'
ActiveRecord::Base.establish_connection(ENV['DATABASE_URL'])
Que.connection = ActiveRecord
Que.migrate!(version: Que::Migrations::CURRENT_VERSION)
class C < ActiveSupport::CurrentAttributes
attribute :test
end
class ApplicationJob < Que::Job; end
class TestJob < ApplicationJob
def run
puts 'Running job'
end
end
class QueJob < ActiveRecord::Base; end
C.test = 5
puts C.test.inspect
j = QueJob.first
puts C.test.inspect
TestJob.enqueue
puts C.test.inspectOutput: |
|
Ok, I've reproduced it in the console and a Rake task of a new Rails app. As I suspected, it only occurs with CurrentAttributes, not the plain class docker run -e POSTGRES_PASSWORD=que -e POSTGRES_USER=que -e POSTGRES_DB=que -p 5432:5432 -d postgres:14.7
gem install rails
rails new my_app
cd my_app
rails g model user
bundle add que
bundle add pg
development:
adapter: postgresql
host: 127.0.0.1
database: que
username: que
password: que
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
timeout: 5000Add to task :derp do
require 'que'
Que.connection = ActiveRecord
require './config/environment'
Rails.logger = Logger.new(STDOUT)
class C < ActiveSupport::CurrentAttributes
attribute :test
end
class QueApplicationJob < Que::Job; end
class TestJob < QueApplicationJob
def run
puts 'Running job'
end
end
C.test = 5
puts C.test.inspect
u = User.first
puts C.test.inspect
TestJob.enqueue
puts C.test.inspect
endThen run: bundle exec rails db:migrate
bundle exec rails derpOutput: |
|
This line is the culprit: ::Rails.application.executor.wrap(&block)in: que/lib/que/active_record/connection.rb Lines 18 to 27 in fb9278e If the method body is replaced with just Edit: Backtrace: |
|
Backtrace of when it's doing the reset: |
|
Wow! Thanks for the prompt response! Based off what you found I have created a monkey patch that solves the issue. Perhaps a better approach would be one that checks for multiple thread usage, or whatever is resetting CurrentAttributes. Trying to track errors through callbacks is the worst. The reason I did not completely replace with yield was the warning comment above the original method. The warn_source_change is my own method (i probably have too many monkey patches) Exception.warn_source_change(Que::ActiveRecord::Connection, 'e4867be7916e315359158dae159fc6e4',
respond_with: :error, message: "Check compatibility / Remove patch")
module Que::ActiveRecord::Connection
def self.wrap_in_rails_executor(&block)
#https://stackoverflow.com/questions/13506690/how-to-determine-if-rails-is-running-from-cli-console-or-as-server
in_console = Rails.const_defined? 'Console'
if defined?(::Rails.application.executor) and not in_console
::Rails.application.executor.wrap(&block)
else
yield
end
end
end |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This can be against expectations but is not necessarily a bug
What is CurrentAttributes:
CurrentAttributes is a class that is often used to keep track of data over a request's lifecycle. This often includes the signed in user. Its treated kind-of like a global variable
Problem Statement:
I have been using CurrentAttributes to pretend to be users during tests over the console. Recently, I noticed that TestJob.enqueue seems to reset CurrentAttributes, wiping that data. This does not happen during actual requests which go through the controller.
Example of issue
The text was updated successfully, but these errors were encountered: