brimdata
typedef variations and marshaling slice of interfaces
The zed lake status command (re-)exposed a bug (we knew about) where arrays of mixed-type values are not handled by zng.Marshal, in particular, MarshalZNGContext.encodeArray() uses the last value of the slice elements as the array type, which does not work for mixed-concrete-type interface values.
The fix is to code mixed-type arrays as an array of unions. Buf if such a slice is typedef'd (as it is with commit.Transaction.Actions) then we need to create a typedef for the array-of-union. However different instances of such a value can have different mixtures of concrete types as elements resulting in different array-of-union types. This in turn causes any containing typedef to also be different.
We could just let this happen and rely upon Zed typedef renaming, which is perfectly legal. However a stronger approach would be to add typedef variations to the Zed data model, which allows a single name to refer to multiple variations, e.g., Transaction.1, Transaction.2, etc. While the marshaling library will not what to do with .1, .2, etc., the runtime should deal with it too, perhaps with operators that handle what is normally a rare condition for non-marshaled lake data.
The zng marshaler context can bookkeep these variations as encountered and take a type-union of the union variations to bound the variations (also, with the union normalization #2145, this should all work out quite well).
NOTE: I worked around this bug in zed lake status by scanning the staging area differently and not sending a commit.Transaction into the mix. Instead I added an actions.StagedCommit, which looks like a CommitMessage without the info, and scan this the same way the journal is laid out.