Problem
docs/examples/m_decompose/python/python_decompose_example.py fails with a KeyError in finalize_result. Found when explicitly running slow tests on a Mac M1 (32 GB).
KeyError: '* The blog post must have a catchy title'
Traceback points to cli/decompose/pipeline.py:431:
"val_strategy": constraint_val_data[cons_str]["val_strategy"],
Root Cause
constraint_val_data is keyed on the raw strings returned by constraint_extractor (e.g. "The blog post must have a catchy title"). Later, subtask_data.constraints is populated by a separate model call which can return the same constraints with slight formatting differences — in this case a * bullet prefix. The dict lookup then fails.
There's no normalisation of constraint strings between the two stages.
Suggested Fix
Strip leading punctuation/whitespace when building or looking up constraint_val_data keys, or normalise constraint strings at extraction time so both stages agree on the format.
Flagging for @AngeloDanducci as the main author of the pipeline.
Problem
docs/examples/m_decompose/python/python_decompose_example.pyfails with aKeyErrorinfinalize_result. Found when explicitly running slow tests on a Mac M1 (32 GB).Traceback points to
cli/decompose/pipeline.py:431:Root Cause
constraint_val_datais keyed on the raw strings returned byconstraint_extractor(e.g."The blog post must have a catchy title"). Later,subtask_data.constraintsis populated by a separate model call which can return the same constraints with slight formatting differences — in this case a*bullet prefix. The dict lookup then fails.There's no normalisation of constraint strings between the two stages.
Suggested Fix
Strip leading punctuation/whitespace when building or looking up
constraint_val_datakeys, or normalise constraint strings at extraction time so both stages agree on the format.Flagging for @AngeloDanducci as the main author of the pipeline.