Caution: The Cloud Dataflow service currently cannot guarantee that changing a coder in your prior pipeline to an incompatible coder will cause the compatibility check to fail. It is recommended that you do not attempt to make backwards-incompatible changes to
Coders when updating your pipeline; if your pipeline update succeeds but you encounter issues or errors in the resulting data, ensure that your replacement pipeline uses data encoding that's the same as, or at least compatible with, your prior job.
I'm adding a new lastModifiedMillis field to MatchResult.Metadata  which requires also updating MetadataCoder, but it's not clear to me whether there are guidelines to follow when evolving a type when that changes the encoding.Is a user allowed to update Beam library versions as part of updating a pipeline? If so, there could be a situation where an updated pipeline is reading state that includes Metadata encoded without the new lastModifiedMillis field, which would cause a CodingException to be thrown.Is there prior art for evolving a type and its Coder? Should I be defensive and catch CodingException when attempting to decode the new field, providing a default value?