Jobs and transactional integrity docs don't seem to be what actually happens in Solid Queue when using a single DB

[leondmello]

Having your jobs in the same ACID-compliant database as your application data enables a powerful yet sharp tool: taking advantage of transactional integrity to ensure some action in your app is not committed unless your job is also committed and viceversa, and ensuring that your job won't be enqueued until the transaction within which you're enqueuing it is committed.

The above text seems to indicate that if you use the same DB for ActiveRecord application models and the Solid Queue models, job enqueuing will only happen if the application model changes are successfully committed to the DB & vice versa.
We changed our implementation to move from a separate DB to a single DB to avail of this. But in practice, we are seeing that this is not the case.

After we installed some debuggers, we found that eventually, this line of code is hit.
That rails method creates a new nested transaction.

Such nested transactions will not roll back all transactions correctly when using something like postgres. We confirmed this behaviour by explicitly rolling back the application transaction after enqueuing the job. The Job record was saved, the application model record was not.

[leondmello]

An extension to this issue: #409

[leondmello]

Maybe a simple fix is to split that up into a find & create!
That does not seem to create a new transaction