GitlabSubscriptionHistory Backwards compatibility across updates
Summary
This is a pitfall to cause production issues: adding columns into GitlabSubscription
would cause errors on production, when migration is run on canary.
This is because production GitlabSubscription
model will log its history into the GitlabSubscriptionHistory
table. After the migration is run, GitlabSubscription
will get to know the new column, and attempts to log that new column, but GitlabSubscriptionHistory
does not have such a column, causing the record creation to err.
Possible fixes
- Have an allowlist of attributes to log to
GitlabSubscriptionHistory
- Always add columns to both
GitlabSubscription
andGitlabSubscriptionHistory
, enforced by Rubocop- This may not be desirable because we may want to ignore a new column
- Have a
GitlabSubscriptionHistory
class method to handle this logging, dynamically filtering out attributes which itself does not have - Maybe we can replace this with
paper_trail
? - Replace the callback with a database trigger
Edited by Josianne Hyson