Plan.default and Namespace#actual_plan cause CrossDatabaseModificationAcrossUnsupportedTablesError

Problem

We have introduced a mechanism for detecting when writes happen to different databases in the context of a transaction https://docs.gitlab.com/ee/development/database/multiple_databases.html#removing-cross-database-transactions .

This mechanism is causing failures when we call Plan.default and/or Namespace#actual_plan because both of these methods are lazily creating records.

At present we believe this is not strictly a problem that we need to solve since it will is likely totally OK that creating a plans record in the middle of a transaction related to ci_pipelines is not important to rollback. Even more these lazy creations likely never need to be rolled back anyway so we probably don't need to push these outside the transactions. Therefore we've implemented a workaround to just ignore these tables !72665 (merged) .

That being said it would be preferable to remove this lazy creation as it forces some slightly hacky code where we need to ignore any updates to plans or gitlab_subscriptions tables and it could in hide a legitimate problem where we are expecting transactions to apply for rolling back any changes to these tables but they do not get rolled back.

It would be good in particular if a domain expert could weigh in and let us know if they are aware of important cases where these gitlab_subscriptions or plans records are being created in a transaction somewhere with the requirement that they must be rolled back if a failure occurs. This will only be a real issue if that transaction is also updating CI tables.

Possible solutions

1. Please confirm the approach we've already taken !72665 (merged) to ignore these tables for this CrossDatabaseModificationAcrossUnsupportedTablesError is safe and let us know if you are aware of where these tables might be deliberately part of a transaction
2. Please look into ways to remove this lazy creation of objects as it is causes problems for our checks but more generally leads to harder to interpret database query analysis as they are a side effect which is not apparent from the method names or expected behaviour