Rails 6.1 creating a record results only in UPDATE transactions-CodePudding

I’m attempting to upgrade from Rails 5.2 -> Rails 6.1. I’ve gotten all the dependencies sorted out, but am now running into an issue where my unit tests are failing because the tests do not seem to be able to create new records in our test sqlite3 1.4 DB.

Dependency Versions Updates:

bundler: 1.3.5 -> 2.2.27
rails (and all immediate Rails dependencies): 5.2.4.1 -> 6.1.4.1
byebug: 10.0.2 -> 11.0.1
pry: 0.11.3 -> 0.13.1
pry-byebug: 3.6.0 -> 3.9.0
sqlite3: 1.3.13 -> 1.4.2
sass-rails: 5.0.6 -> 6.0.0
haml-rails: 1.0.0 -> 2.0.0
haml: 5.0.4 -> 5.1.4
responders: 2.4.0 -> 3.0.1
bullet: 5.8.1 -> 6.1.4
jasmine-rails: 0.14.7 -> 0.15.0
actionpack-action_caching: 1.2.1 -> 1.2.2
concurrent-ruby-ext: 1.0.5 -> 1.1.9
delayed_job_active_record: 4.1.4 -> 4.1.6

When I insert a breakpoint into our tests, and attempt to do a simple create on a model, I see that .save or .create returns true, however, the record has no ID, and the count for that model remains unchanged. I have a similar experience when running save, as it returns true, even though the record was not actually saved. What’s strange is that running .valid? also returns true . Has anyone ever dealt with a similar issue before?

Debugging and showcasing the SQL reveals the following

@b.save!
-- :   TRANSACTION (0.1ms)  SAVEPOINT active_record_1
-- :   P Load (0.1ms)  SELECT "p".* FROM "p" WHERE "p"."id" = ? LIMIT ?  [["id", 2], ["LIMIT", 1]]
-- :   B Update (0.1ms)  UPDATE "b" SET "c_id" = ?, "d" = ?, "e" = ?, "f" = ?, "g" = ? WHERE "b"."id" IS NULL  [["c_id", 3], ["d", 0], ["e", 7], ["f", 200], ["g", "Z"]]
-- :   P Update (0.2ms)  UPDATE "p" SET "c" = ? WHERE "p"."id" = ?  [["c", "F"], ["id", 2]]
-- :   TRANSACTION (0.1ms)  RELEASE SAVEPOINT active_record_1

The main thing to focus on is that calling .save on a new record results in an UPDATE transaction to table B instead of an INSERT operation. The before_save callback can be seen to run successfully, but the before_create callback does not run.

CodePudding user response：

The issue ended up being a problem with our use of the protected_attributes_continued gem

https://github.com/westonganger/protected_attributes_continued/pull/18

Upgrading protected_attributes_continued from 1.5 -> 1.6 fixed the issue