You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@TonyCTHsu Yeah, however, we'd have to go through and load all of the constants underneath app/graphql which for our small app is only 15 files, but for our larger monolith is 667 ruby files.
This seems similar to #2709 and our configuration would align with Autoloading and Reloading Use Case 3 where we should specify the class as a string that uses constantize to resolve it to the class later?
I have looked into the exception_controller option from #2709 . This was solved because I found out that the option is useless. It is deprecated and will be removed. Hence, I have not addressed the zeitwerk autoloading problem yet.
From Autoloading and Reloading Use Case 3, passing a string instead of a class seems reasonable to me. However, it failed with NameError from Object.get_const(schema_string), because the specified schema class has not yet been loaded.
I agree that our configuration should work smoother with zeitwerk, but it is going to require a lot of fundamental changes.
Currently, only the specified schemas are being instrumented, however, I think it would be better to instrument all schemas when no specification. This could help circumvent the trouble for zeitwerk autoloading for some cases (I supposed most of our users are instrumenting all the schemas). What do yo think?
For now, the workaround I could provide would be adding this configuration in your Rails app (assuming your schema is sitting under such path).
Current behaviour
Rails commands fail due to the error
uninitialized constant MyAppSchema
Expected behaviour
Application starts and monitors just like it did on Rails 6.1.
Steps to reproduce
Environment
Datadog.configure ...
):c.tracing.instrument :graphql, schemas: [MyAppSchema]
The text was updated successfully, but these errors were encountered: