hmm the failing time is quite close to merge of PR#9050 might that be the root cause? This issue manifests if we load some models too early in the init process (when Setting was always first, then it was all cool) but now if the first loaded model is no longer Setting, it bombs if some (no idea what identifies some) is first, this happens … I’ll try to investigate why, but I guess the migration should not change just to resolve the issue, as it is not actually the root cause
You don’t think this is related to the Rails upgrade then? I don’t think it is related to foreman_puppet, either. The main changes that were added in 4.0.0 are related to webpack and the host details page.
in that case it is about load order of Rails models, the migration loads LookupValue first.
My guess (and be aware this is just working theory) is that classes named Something::Base make the Rails trip, as rails use Activerecord::Base inheritence in the algorithm to determine a table name, but without explicit namespace (so there is Base).
If there is another Base class in a scope of the class (like some Host class of ours, but also Nic, Facet), it may trip up the resolving of table_name, and if that trips the first time we’re resolving it for ApplicationRecord, then all models resolve their table name to application_records.
Possible mitigations:
load ApplicationRecord explicitly early (this is bad for zetwerk, but at least it is only one specific class.
switch to Zeitwerk (which should resolve the namespace confusion), but we are not ready to do so just yet (I mean core is mostly ready, but plugins are not)
Given both ways somehow, somewhere involve Zeitwerk, I’d prefer “going forward (with a workaround)” aka option 1 over “revert and re-visit” aka option 2.
