https://avo.cool logo
Join Discord
Powered by
Adrian M in my Jumpstart Pro app I have
# avo-2
a
@lemon-wall-20836 in my Jumpstart Pro app, I have a concern defined. Avo can't find that concern. I'm guessing it's an autoload issue or something that has to do with Avo being a gem? How can I fix this
l
code or it didn't happen. can you post a GitHub issue with the code that is or is not loaded?
a
class Avo::ToolsController < Avo::ApplicationController def workflow_test @page_title = "Workflow test" add_breadcrumb "Workflow test" @toolbar_data = ElementDefinition.definitions_for_controller end end
irb(main):037:0> ElementDefinition.definitions_for_controller ElementDefinition Load (132.6ms) SELECT "element_definitions".* FROM "element_definitions" WHERE "element_definitions"."executor_class" IS NOT NULL => [{:label=>"Majestic: Retrieve Backlink Data", :inputs=>1, :outputs=>1, :locals=>{:label=>"Majestic: Retrieve Backlink Data"}, :template=>"workflows/nodes/default"},
web_1 | 21:54:04 web.1 | Processing by Avo::ToolsController#workflow_test as HTML web_1 | 21:54:04 web.1 | User Load (5.8ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT $2 [["id", 2], ["LIMIT", 1]] web_1 | 21:54:04 web.1 | ElementDefinition Load (4.6ms) SELECT "element_definitions".* FROM "element_definitions" WHERE "element_definitions"."executor_class" IS NOT NULL web_1 | 21:54:04 web.1 | ↳ app/models/element_definition.rb:40:in `map' web_1 | 21:54:04 web.1 | Completed 500 Internal Server Error in 561ms (ActiveRecord: 262.4ms | Allocations: 17832) web_1 | 21:54:04 web.1 | web_1 | 21:54:04 web.1 | web_1 | 21:54:04 web.1 | web_1 | 21:54:04 web.1 | NameError (uninitialized constant IsWorkflowAction): web_1 | 21:54:04 web.1 | web_1 | 21:54:04 web.1 | app/organizers/workflow_actions/majestic/retrieve_backlink_data.rb:6:in `' web_1 | 21:54:04 web.1 | app/organizers/workflow_actions/majestic/retrieve_backlink_data.rb:4:in `' web_1 | 21:54:04 web.1 | app/organizers/workflow_actions/majestic/retrieve_backlink_data.rb:3:in `' web_1 | 21:54:04 web.1 | app/models/element_definition.rb:40:in `block in definitions_for_controller' web_1 | 21:54:04 web.1 | app/models/element_definition.rb:40:in `map' web_1 | 21:54:04 web.1 | app/models/element_definition.rb:40:in `definitions_for_controller' web_1 | 21:54:04 web.1 | app/controllers/avo/tools_controller.rb:5:in `workflow_test'
it runs fine on the regular rails console
but if I access it in a tool, it bombs out because it can't find the concern
# frozen_string_literal: true module WorkflowActions::Majestic class RetrieveAnchorText extend ::LightService::Organizer include ::IsWorkflowAction def self.call(params) with( #foo: params[:foo], #bar: params[:bar] ).reduce(actions) end def self.actions [ #Majestic::OneAction, #Majestic::TwoAction, ] end end end is an example organizer
I tried with and without the :: in the include
without the :: (my initial default) it was: uninitialized constant WorkflowActions::Majestic::RetrieveBacklinkData::IsWorkflowAction
l
pfff. it's so difficult to read this here. it would be so much more easier in a GitHub issue
I don't see the concern
please create a reproduction repo so we can test out the code. then add it to an issue https://avo.cool/new-issue
a
ok, so I was building a sample repo for this, and was able to isolate WHAT is happening. I'm not 100% sure what the best way to fix it is. I simply used plain ruby classes for simplicity, and a single simple concern. I placed two test classes in app/organizers, one that included a concern and one that did not. I placed the concern in app/concerns I set up a simple Tool in Avo, and added to the tools controller: @without_concern = TestWithoutConcern.test_method @with_concern = TestWithConcern.test_method At all times the Rails console could access both test classes. In the above baseline, I got a missing constant error from ToolsController. Avo was apparently unable to find the test classes in app/organizers I then moved them to app/models, and Avo was able to find both classes. However, now it was unable to find the concern. I moved the concern to the existing folder app/models/concerns (JSP puts some concerns in there, apparently) and Avo was able to find and access the concern just fine, and everything worked as expected. So clearly while I can access app/concerns and app/organizers from the Rails console and the JSP side of the web app, I can't access them through Avo. I'm assuming that there are paths not being added to autoloading, but I don't do a lot of engine work so I'm not sure.
l
just to make sure I understand it correctly, the classes that can't access the concerns are test classes?
a
For the purposes of a repro, yes
the initial issue was regular classes
class Avo::ToolsController < Avo::ApplicationController def concern_test @page_title = "Concern test" add_breadcrumb "Concern test" @without_concern = ::TestWithoutConcern.test_method @with_concern = ::TestWithConcern.test_method end end
That's the Avo syntax
if everything lives under app/models, it works great
l
TestWithoutConcern
is that an actual minitest file?
a
sorry, that's not what I meant by 'test class'
l
oh
a

https://cdn.discordapp.com/attachments/1121923199962206318/1122931664906092606/image.png▾

just a 'class for testing' not a unit test of any kind
l
yeah, that's why we need a reproduction repo
I'd love to test it out
it works on my end 🙂
yeah. create a reproduction repo if this still persists. I am 99% sure this isn't an Avo issue
a
it's likely some interaction between JSP and Avo then
l
hmmm. I think there might be a typo or something honestly 🫣
but it's all good. I'm glad it works
a
I'm not sure how, it works flawlessly from the console, and the only thing I changed was the file location, and then it worked
is there a way for me to see what paths the Avo Engine is loading from?
l
it uses zeitwerk under the hood
I guess if you dump 
Rails.autoloaders.main
you should get the bulk of the paths
a
my other apps are all Rails 5 based, so not super familiar with zw's internals
l
we do this on boot time
a
yeah I was looking at that file earlier
l

https://cdn.discordapp.com/attachments/1121923199962206318/1122935762485256232/CleanShot_2023-06-26_at_20.05.342x.png▾

https://cdn.discordapp.com/attachments/1121923199962206318/1122935762682400778/CleanShot_2023-06-26_at_20.05.452x.png▾

yeah. so that's what we add to the autoloader
otherwise, we are not removing anything from the autoloader
it's Rails default
a
I'll have to see what Chris is doing in JSP then
l
I don't think he does anything either
a
ok, now if I move them back it's working correctly still. I wonder if I had some wierd state somewhere.
and now going back to the original code, it works fine. The only thing that changed is I ended up restarting Docker along the way. I'm going to chalk it up to something related to that.
PreviousNext
Powered by