Make it so that an AI change can automatically figure out whether a change is breaking or not.
Perhaps this issue should be split in two, because prevention and detection may be sufficiently distinct to merit their own issues, but for now we're starting with one issue.
Now that we're using rmp_serde (#1908) I believe we can get some measure of prevention by using serde's default attribute for new attributes.
Detection is tricky, but I think we want to make a few marker traits that we use to tag types that are used in messaging, which roughly fall into the category of requests and messages (although some messages are responses, but currently there's no formal distinction). The idea would be to have a trait like TableMessageType and then define that (with a custom derive macro) in such a way that all the types used in the TableMessage enum must also have TableMessageType implementations (again, probably with a derive macro). We'd have to also mark all the primitive and foreign types with TableMessageType. We'd do this for lobby requests and responses, table requests and responses and the small number of other things we pass over the wire.
Then, the AI can be told to watch for breaking changes to any TableMessageType type. A breaking change would be anything that alters the shape or semantics that can't be recovered automatically (like serde's default attribute).
I'll want to research this more before we work on this.
Make it so that an AI change can automatically figure out whether a change is breaking or not.
Perhaps this issue should be split in two, because prevention and detection may be sufficiently distinct to merit their own issues, but for now we're starting with one issue.
Now that we're using rmp_serde (#1908) I believe we can get some measure of prevention by using serde's default attribute for new attributes.
Detection is tricky, but I think we want to make a few marker traits that we use to tag types that are used in messaging, which roughly fall into the category of requests and messages (although some messages are responses, but currently there's no formal distinction). The idea would be to have a trait like
TableMessageTypeand then define that (with a custom derive macro) in such a way that all the types used in theTableMessageenum must also haveTableMessageTypeimplementations (again, probably with a derive macro). We'd have to also mark all the primitive and foreign types withTableMessageType. We'd do this for lobby requests and responses, table requests and responses and the small number of other things we pass over the wire.Then, the AI can be told to watch for breaking changes to any
TableMessageTypetype. A breaking change would be anything that alters the shape or semantics that can't be recovered automatically (like serde's default attribute).I'll want to research this more before we work on this.