-
-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modules don't get autovivified #159
Comments
Could you please inspect the autoloader to help me understand the setup? What does
print? |
It prints the following (I removed the irrelevant parts):
Maybe |
I am mostly interested in the autoload paths, could you paste the whole collection please? |
(They are the contents of |
Of course! Here are the
|
Thanks! Next step:
What's the output? |
|
when executing the spec above without defined module
|
Does that mean that |
I'd like to see the log printed in a situation in which the constant is not found. |
I executed the spec with following changes
it prints the following:
and
without anything related to the cache module or the Cache::Base class |
It is strange that We should see at least the same series of autoload calls. Please do not edit the log of the autoloader, I'd like to see it all to spot differences. Could you share the full autoloader log both in success and failure use cases? |
BTW, if there is sensitive information please feel free to email me at fxn@hashref.com. |
When setting Hope the autoloader logs now aren't necessary anymore (I am indeed not allowed to post the full log, because of sensitive information). Thank you |
I did not said Zeitwerk has an issue with these settings. I am trying to gather as much context as possible to help diagnose. If you cannot share information, let's try some baby steps. Is there a file called |
I am asking this because I see a discrepancy. The issue description says that you get
but autoload logs above say
This does not square. We need to understand where's the issue. With autoloading logs it would be faster, but don't worry, we'll try to hunt it down going step by step. |
The No, there is no Thank you for you patience! |
It is really strange that we get this error message
and Does the application load |
Would it be possible to trigger
with autoloading logging enabled, and share only the log lines that mention "cache" case-insensitive? Then do the same in |
With following diff
I get the following output
when switching to
I removed bootsnap and spring to be sure, that they don't have problems with zeitwerk. I can't explain why there is suddenly no |
@enthusiasmus There's something really funky going on. For that to be possible, Zeitwerk needs to think no loader is managing Could you please add |
I have seen more things off. According to the logs, the application loads
which should not happen, the loader would detect both Also, in the second run This is all very strange, but without logs, it is difficult to understand. (*) This should be fixed at some point, it is going to be an error condition in Rails 7.0. |
And of course, we have the mystery of the phantom |
Hi again! Wondering if we are in a deadlock, did you see the question in #159 (comment)? If yes no hurries, just wanted to double-check. |
Dear fxn! No deadlock, I will post the next logs tomorrow! Thank you |
I tried to get the output of
and with
both runs are successful! independently from the configuration of the cache_classes. Now I am confused, because the only thing I did was restarting the container and execute once again a bundle install. Maybe the Problem is gone? |
Even with spring and bootsnap reactivated - the tests are passing with both configuration states. |
Interesting!!! I can tell you that, if memory does not fail me, module autovivification has worked correctly since the beginning. The only thing that needed polishing was autovification + multi-threading, fixed in March 2019. Any project with an implicit namespace is doing this (that is, many projects). Of course, you never know, maybe you hit some weird edge case that is new, but the reproduction seemed so simple (just run a spec), that... I was a bit skeptical. In any case, you never know, and we had to understand. I wonder if this could be some kind of combination of things that involve shared file systems or something. That is, not exactly a problem in Zeitwerk, but something in the execution context external to the library. Again, nowadays a lot of people use Docker, but who knows! So... what would you like to do? Do we close and reopen if it happens again? |
Yes, that could be! Yeah, lets do this. Thank you very much for your time and your support! |
Dear maintainer,
I try to update our application to rails 6.0.3.3 which uses zeitwerk 2.4.2
I need to define
additional to
to be able to execute the following spec
otherwise is raises an
My settings are:
The module should get autovivified, but it doesn't. Any ideas?
Thx! Best regards
The text was updated successfully, but these errors were encountered: