7.0.2 version is raising "uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState"

[immccc]

Hi,

In our project, we are not directly using activesupport, but grape does. This is fetching latest version of activesupport, which is currently 7.0.2.

Problem

Starting up the application is raising the following exception:

NameError:
  uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:184:in `current_thread_backend'
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:103:in `backend='
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:201:in `<module:ActiveSupport>'
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:11:in `<top (required)>'
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/core_ext/array/conversions.rb:3:in `require'
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/core_ext/array/conversions.rb:3:in `<top (required)>'
...

Gemfile.lock

specs:
    activesupport (7.0.2)
      concurrent-ruby (~> 1.0, >= 1.0.2)
      i18n (>= 1.6, < 2)
      minitest (>= 5.1)
      tzinfo (~> 2.0)
      zeitwerk (~> 2.3)
# ...
    grape (1.6.2)
      activesupport
      builder
      dry-types (>= 1.1)
      mustermann-grape (~> 1.0.0)
      rack (>= 1.3.0)
      rack-accept

...

Potential fix

Shouldn't constant ActiveSupport::XmlMini::IsolatedExecutionState be ActiveSupport::IsolatedExecutionState as found in xml_mini.rb?

Temporary solution on our place

We have forced our Gemfile to contain active_support fixed to working version 6.1. This is a workaround, as we are adding a dependency we are not using in our own codebase, but as a subdependency.

[dblock]

Was this supposedly fixed in #2208 and released in 1.6.1? @ericproulx

Either way I'd try to reproduce this in a spec/Gemfile/Appraisal.

[ericproulx]

Was this supposedly fixed in #2208 and released in 1.6.1? @ericproulx

Either way I'd try to reproduce this in a spec/Gemfile/Appraisal.

It was supposed to be fix. I'll check

[ericproulx]

@immccc could you provide a complete Gemfile.lock. I couldn't reproduce with a brand new rails app. Thanks

[immccc]

Hi @ericproulx , thanks for taking a look!

Sorry, but unfortunately can't share full Gemfile.lock since I'd have to do a lot of cherry-picking, removing internal/confidential packages. Anyhow, the dependencies pointing to activesupport are just the ones I exposed when I opened the issue and I don't think you'll find relevant information on there.

I checked fetched sources from activesupport v7.0.2 gem and problem can be found easily:

From the above snapshots, IsolatedExecutionState is assumed to be in the same path than XmlMini, which is ActiveSupport::XmlMini. However, it's actual path is ActiveSupport.

__

In addition, I think I didn't explain myself about how to reproduce the issue:

1. We made a fresh new grape app.
2. After bundle install, grape declares a dependency to activesupport (as shown in the top comment)
3. The fetched activesupport version is 7.0.2.
4. When starting the grape server, app launches the error posted in top comment.

Hope that helps.

[dblock]

@immccc Can you please make a trivial application that reproduces this and put it up on GitHub or make a PR with a spec that fails here?

[immccc]

@dblock I don't think that's needed. In order to check what's happening here, just check which version of avtivesupport is fetching Grape 1.6.2. And if it's 7.0.2, bingo!

Also please take a look to linked snapshots from my comment above, where you can see how reference used to IsolatedExecutionState is not matching to its declaration.

Thanks!

[dm1try]

Also please take a look to linked snapshots from my comment above, where you can see how reference used to IsolatedExecutionState is not matching to its declaration.

This is how Constant resolution works in Ruby, there is nothing suspicious.

[dm1try]

The provided log does not contain the full trace path so it's not clear that's going on on your side.

[dblock]

@immccc yes I can debug the issue, reproduce and probably fix it and so can @ericproulx who fixed it in the first place, but that will take some unknown amount of time given that nobody is paid to do this work. So help us help you so we can do this faster?

Turn the problem into an integration test with the locked version of ActiveSupport that demonstrates the issue and PR it. If the problem is just the new Activesupport, then a new Appraisal will do and we'll see it happen. And maybe you'll find out what the problem is and fix it yourself!

[immccc]

@dblock no worries, I'll test a "hello world" and come back with it when I have some time.

[lvonk]

This happens when for instance if, in your project, you do require 'active_support/core_ext/object' without requiring require 'active_support' first. The require require 'active_support' is needed to do some initialisation for active_support.

[dm1try]

@lvonk yeah, and this was fixed in #2206.

[dblock]

But that was in 1.6.1, and the report above says 1.6.2?

[immccc]

Sorry for coming back late. Just tried to reproduce locally on a Grape app from scratch (I'm using https://github.com/zachrab/grape-hello-world )

This time, after removing original Gemfile.lock and bundle install, ActiveSupport is pointing to version 7.0.2.2. It's running fine. I forced to have version 7.0.2 and still working fine.

Not sure why I cannot reproduce, as the other project was not making active use of ActiveSupport.