-
Notifications
You must be signed in to change notification settings - Fork 4.1k
schemachanger: future-proof event logs #73308
Description
Is your feature request related to a problem? Please describe.
The declarative schema changer currently emits event logs. Coverage is incomplete because, well, the schema changer is incomplete and not turned on yet. That's fine by me, I'm concerned that in the future, every time we turn on a new schema change, we're chasing down a slew of test failures caused by bad or missing event logging.
Describe the solution you'd like
I'll welcome any solution which allows us to effectively not worry about event logs. Ideas:
- The expectations regarding event logs are effectively encoded in the logic tests, so perhaps run the logic tests with the new schema changer somehow. This idea seems to have broad consensus already.
- The EventLog operation takes an element and a direction and effectively maps it to at-most-one eventpb message. It seems that since we already have most element types defined, we could already implement this mapping right now. Even if it's not exercised, the implementation seems straightforward enough to not be a cause of concern.
- Perhaps have a test that uses reflection somehow to ensure that it's possible to emit all kinds of eventpb messages somehow. This will protect us if someone outside the team adds a new eventpb message type but forgets to update the mapping in the operation.
- There are a lot of different element types and a lot of eventpb messages, this means it's probably worth coding this cleanly in a way that makes it easy for random contributors to add support for new types.
Event logs are not at the front of anyone's mind and they're easy to forget about. Let's make it so that every time we're reminded of their existence we can fix things so as to forget about them as fast as possible.
Jira issue: CRDB-11531
Epic CRDB-60938