Regression regarding unavailable database in 4.x+ versions

[colszowka]

Hi there,

I believe the bugfix for #179 via #182 has introduced a regression for the original fix introduced in #156 - we are failing to upgrade to version 4, which is blocking us from upgrading forward to Rails 7.2, because (only on CI) our application fails to boot on an accepts_nested_attributes_for store model property, as it complains about a missing table.

I am failing to reproduce this locally so far, but on CI our setup is like this:

• Postgres docker image with credentials configured
• Rails app rspec specs get connected via a DATABASE_URL env var that points to that single instance

I can imagine this has to do with the "missing" test/development database, as we only provide a single database here, and I know rails has a bit of a history of trying to connect to development in test env regardless IIRC.

Not sure either what the fix for this is, considering https://github.com/rails/rails/issues/52685, but as it stands we're blocked from upgrading here and it would be great if we could get the original problem fixed by #156 back in order somehow

[colszowka]

(A side note, the adjustments made to StoreModel::NestedAttributes.nested_attribute_type in #182 did not adjust / remove the method comment, which still refers to the internal rails API used and doesn't make much sense now anymore)

[DmitryTsepelev]

Hey! Yep, I tried to find a workaround for this and failed to find a substitution, since, as mentioned in the Rails repo, it's the internal part of the framework

[colszowka]

@DmitryTsepelev So, in the meantime I was able to reproduce the issue we were seeing on CI locally by mirroring the setup flow I described above locally, improving the time it took me to figure out a way how to make the test suite to boot locally again.

While this doesn't fix the actual issue (not sure if there is a fix possible as long as no public API is added to rails as mentioned over in https://github.com/rails/rails/issues/52685), at least we can upgrade now and get our CI passing, so maybe anyone who runs into this issue as well can at least remedy it for the time being.

I was able to reproduce it for our app by running postgres (in our case postgis, but it should be the same with regular PG) inside docker, and then running specs with a DATABASE_URL, somewhat like this:

docker run -it --rm -e POSTGRES_DB=ci -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=ci --publish 3456:5432 postgis/postgis:17-3.5-alpine
DATABASE_URL=postgis://postgres:ci@localhost:3456/ci bundle exec rspec spec/models/widgets_spec.rb

This then leads to the dreaded error, because due to the attribute_types call not being deferred anymore, somehow rails very early in the boot process now tries to get the table schema, which fails, because the automatic test schema setup didn't work. This affects even rails dbconsole, which fails to boot.

So what I did to fix this was to basically manually load db/structure.sql into the postgres db on our CI script using psql, and now we have it passing again.