GeneratedAttributeMethods is inconsistently included in the RBI files

[adamk9k]

I’m running into a weird issue. We run tapioca dsl --verify on CI and recently it started to detect uncommitted changes and indeed when running tapioca dsl on the CI it does generate differently than it does on local. To give you an example, the model

class MyModel < ApplicationRecord
  self.primary_key = :id

  self.table_name = "my_table"
end

will generate the following rbi file on local (M1 machine)

class MyModel
  extend CommonRelationMethods
  extend GeneratedRelationMethods

and on CI, which runs on x86 linux I get

 class MyModel
+  include GeneratedAttributeMethods
   extend CommonRelationMethods
   extend GeneratedRelationMethods

Happens for multiple models that were not even modified recently. Tested both on tapioca (0.13.3) and the newest tapioca (0.15.1). We don’t have any compiler options.

CI is Github actions with ubuntu-latest is Ubuntu 24.04 TLS x86 architecture and on local I'm running on an M1 Macbook Air.

Besides the architecture, there is no difference between the two setups, environment variables and Tapioca config file is the same. Any ideas would be appreciated. Thanks!

[KaanOzkan]

Make sure that locally database is setup properly and my_table exists. We return early in the compiler if we can't get the table: https://github.com/Shopify/tapioca/blob/b3cec5b6752d35779f956f60eb3801b07da408fc/lib/tapioca/dsl/compilers/active_record_columns.rb#L131

If the setup is correct I'd also make sure the table_name assignment is running upon application boot before we trigger the DSL compiler. If not the code would be looking at a my_model table instead of my_table.

[adamk9k]

Thanks, I have the verify step running after

  RAILS_ENV=test bundle exec rails db:drop
  RAILS_ENV=test bundle exec rails db:create
  RAILS_ENV=test bundle exec rails db:schema:load
  RAILS_ENV=test ./bin/tapioca dsl --verify

So the table should definitely be created.

[fazo96]

I randomly started running into the same issue these few weeks. Sometimes when running tapioca dsl locally, a specific model gets def table_name= and def table_name in the rbi file while on CI these methods are not in the rbi file.

I could not figure out what causes this to trigger.

[egiurleo]

@fazo96 were you able to resolve the issue?

[fazo96]

Unfortunately no @egiurleo - it only happens with one specific model class out of perhaps a hundred total in this project, and only happens to two people on the team.

We have been dealing with it with manually editing the affected rbi file after generating it on our local machine. I use two machines for work and it happens on both of them. I encapsulate the dev environment into a devcontainer (including the DB installation) and if I re-create it from scratch it still happens

All that to say I have no idea what causes it 🤷‍♂

[KaanOzkan]

table_name= is strange, were you able to identify which tapioca Rails call is generating the methods?

You can point your project to a local tapioca, add a conditional breakpoint in here based on the method name and run bt in a ruby/debug session to get more info. It should show you who called it and from there you can identify which rails API call resulted in tapioca wanting to generate a table_name= method.