Found by an independent adversarial review (fuzzing). Pre-existing in the merged converter (#364).
The converter contracts to fail with a clear ConversionError, never a bare traceback — its own stash.py comment calls this "this module's own never-a-bare-traceback contract". Wrongly typed values break that. Well-formed input never crashed, and malformed YAML, empty files, top-level scalars and missing keys all still fail cleanly; it is specifically values of the wrong Python type.
to-ossie
| Input |
Result |
a column with no name |
KeyError |
name as int, null or bool (also model name as int) |
TypeError: normalize() argument 2 must be str |
aggregation as a list or dict |
TypeError at tml_to_ossie.py:1029 |
data_type as a list |
TypeError |
formulas[].expr as int |
TypeError |
join on as int |
AttributeError |
db_column_name as int |
TypeError |
columns, model_tables, properties or join destination as the wrong container type |
AttributeError |
to-tml
- A
custom_extensions stash with _v: 1 and wrongly-typed values — at model, field, metric and relationship scope — raises AttributeError / ValueError / TypeError.
- Documents that already fail the schema (
expression as a string, dialects as a dict, a dialect expression as int, name as int, source as int, metrics as a dict) crash rather than being rejected.
Why it is worth fixing as a class
These are all the same shape — a value read as a string or container without checking — so a single guard at the read boundary would cover most of them, rather than eight separate fixes.
The to-tml stash cases are the more likely to be hit in practice: a hand-edited Ossie document is exactly the use case the portable format exists for, and the stash is the part a user is least likely to edit correctly.
Found by an independent adversarial review (fuzzing). Pre-existing in the merged converter (#364).
The converter contracts to fail with a clear
ConversionError, never a bare traceback — its ownstash.pycomment calls this "this module's own never-a-bare-traceback contract". Wrongly typed values break that. Well-formed input never crashed, and malformed YAML, empty files, top-level scalars and missing keys all still fail cleanly; it is specifically values of the wrong Python type.to-ossienameKeyErrornameas int, null or bool (also modelnameas int)TypeError: normalize() argument 2 must be straggregationas a list or dictTypeErrorattml_to_ossie.py:1029data_typeas a listTypeErrorformulas[].expras intTypeErroronas intAttributeErrordb_column_nameas intTypeErrorcolumns,model_tables,propertiesor joindestinationas the wrong container typeAttributeErrorto-tmlcustom_extensionsstash with_v: 1and wrongly-typed values — at model, field, metric and relationship scope — raisesAttributeError/ValueError/TypeError.expressionas a string,dialectsas a dict, a dialectexpressionas int,nameas int,sourceas int,metricsas a dict) crash rather than being rejected.Why it is worth fixing as a class
These are all the same shape — a value read as a string or container without checking — so a single guard at the read boundary would cover most of them, rather than eight separate fixes.
The
to-tmlstash cases are the more likely to be hit in practice: a hand-edited Ossie document is exactly the use case the portable format exists for, and the stash is the part a user is least likely to edit correctly.